x86_64 blocks i386?

[Nils Philippsen]

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
simultaneously.

>  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[64] 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
the exception.

Nils
-- 
     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