For your consideration: Secondary Architectures in Fedora

[David Woodhouse]

On Wed, 2007-05-30 at 09:22 -0400, Jesse Keating wrote:
> Nobody said it was going to be a silent failure.  However a failure on say ARM 
> shouldn't stop the very important kernel build from succeeding on 
> i386/x86_64/ppc/ppc64.  It should throw off alarms to the kernel maintainer 
> and to the arch maintainer for ARM and it should be looked into.  It just 
> should NOT stop or hinder the progress of Fedora on the primary arches. 

I see no reason to believe that it _would_ "hinder the progress of
Fedora on the primary arches". We've seen very little evidence of that
so far. As I said, I think you're 'solving' a problem that doesn't
exist.

There are three common possibilities when a package fails to build on an
architecture that it _used_ to build on: 

 1. A spurious build or test failure which happens on all arches
    but intermittently.
 2. A simple error introduced in the package update.
 3. Something 'hard' which the arch team need to look into.
 4. A compiler bug.

(OK, that's four. I'm not going to do the whole Spanish Inquisition
sketch; don't worry.)

The third is the only case where the appropriate action is just to
ExcludeArch the package -- and it's the least common, at least amongst
packages which _used_ to build on the arch in question.

All the others should get immediate action from the package maintainer
-- even if the eventual result of #4 is a temporary ExcludeArch, that
should only be done after the appropriate bug has been filed against the
compiler. In fact, even #3 should get immediate action from the package
maintainer -- they should diagnose the problem sufficiently that the
arch team can deal with it, in much the same way they'd create a test
case for a compiler bug.

Thus, allowing the build to 'commit' when it has failed on one or more
architectures is almost _always_ the wrong thing to do.

It's not as if it takes long to look at the failure, diagnose it and
either fix it or file an ExcludeArch bug.

The only disadvantage is the amount of wall-clock time it takes to put
it through the build system again -- and that's negligible for most
packages. I suppose it would perhaps be possible to allow the package
maintainer to file a _retrospective_ ExcludeArch bug, and let the
partially-failed build then be 'committed' anyway -- but then the
ExcludeArch: in the archived specfile doesn't match reality, and I
really don't think it's worth the effort or the inconsistency.

-- 
dwmw2