x86_64 blocks i386?
nphilipp at redhat.com
Mon Mar 21 15:21:46 UTC 2005
On Mon, 2005-03-21 at 15:36 +0100, Michael Schwendt wrote:
> It looks as if a rule is needed. For new packages, build failure on one
> arch blocks builds for all archs?
Well, "blocks releases" would be a good idea for new packages. Builds
should be done so problems on different arches can be solved
> No ExcludeArch permitted for new packages anymore?
I'd limit ExcludeArch/ExclusiveArch for situations related to the nature
of the package, not the packaging (or its problems). So: no
ExcludeArch/ExclusiveArch to work around build problems, but for things
like the Synaptics touchpad driver that isn't sensible on most arches.
> That alone would be quite rigorous and lead to
> exclusion of packages which are just not designed to work on non-i386
> (e.g. due to endianess related implementation issues or weird use of
> C-style casts).
I'd say this should be the exception, i.e. if someone would want to
introduce something that doesn't build on anything except i386, (s)he
should have to hop over a higher hurdle than for a well-behaved package,
e.g. we could require a certain higher number of sponsors for such
packages. Usually when code cuts these corners you mentioned, the
chances are high that it's bad in other places as well, so a certain
amount of encouragement to fix these issues can't hurt ;-).
> What happens if no resources are available to look into
> such a problem (and no upstream developers either)?
In the case of no upstream the maintainer should be willing and able
cover the upstream role by himself. The quality of the packages -- and
by proxy the overall quality of the repository -- depends on the
packager and upstream roles being filled.
> The same can happen
> during big[ger] version upgrades.
We really need to talk about whether something like arch-maintainers
contrary to package maintainers, people where the latter can come to if
they have problems on their specific architectures, makes sense.
> As it is currently, the majority of packages is prepared and tested on
> i386 and rebuilt for x86_64 (and likely ppc some day besides dwmw2's
> private builds). If no arch-specific co-maintainers exist, the packages
> built for x86_64 are fully untested until some users tries them out. And
That's why there is -testing I believe...
> it has happened before, that such an untested built either crashes right
> at the start (e.g. geomview) or at a later point (e.g. anjuta).
> Trying to support multiple archs equally from the start is an admirable
> goal, but just not feasible until arch-specific co-maintainers kick in
> (or the built stuff "just works" and no difficult issues come up).
Still I would say that we should aim high first and make cutting corners
Nils Philippsen / Red Hat / nphilipp at redhat.com
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." -- B. Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
More information about the fedora-extras-list