For your consideration: Secondary Architectures in Fedora

[David Woodhouse]

On Wed, 2007-05-30 at 10:43 -0400, Jesse Keating wrote:
> On Wednesday 30 May 2007 10:33:36 David Woodhouse wrote:
> > I don't think anyone suggested that you must delay the security fix
> > while someone debugs and fixes a compiler problem like that (although
> > usually if it's a security fix it'll be a minimal patch, and any
> > compiler bug you now trigger should be fairly easy to work around).
> 
> It's not often the new patch that triggers it.  It's say a build was done in 
> Jan that worked across the arches.  Then gcc was updated in Feb, then May, 
> and now in June we have to do a security bump for the build, only now a new 
> gcc is used that is completely unable to build the package for the off 
> arches, something that built just fine, only a minimal patch being added.  
> This has happened in the past, and likely to happen again in the future.

Yeah. The periodic rebuilds which mdomsch does should help with that. I
must get them going on PPC some time soon.

> > The only delay you currently have is the time it takes to add the
> > ExcludeArch: to the specfile and file the ExcludeArch bug -- and then
> > for the build system to rebuild the package itself. You can even find
> > the test case and file the compiler bug (on which your ExcludeArch bug
> > will depend) _after_ you've built the new package with the ExcludeArch.
> >
> > Has that _really_ been so much of a problem for you?
> 
> On a build that takes 6~8 hours to complete?  Yes.

There aren't many of those, thankfully.

> Yes.  Adding delays in for an arch that is potentially 1% of our userbase is 
> just insane.

And the number of cases where the package takes 6-8 hours to build _and_
has an arch-specific bug which should lead to an ExcludeArch _and_ we're
in a desperate hurry to release it.... you think that's more than 1%?
Seems rather a strange case to optimise for, to me.

Allowing partially-failed builds to make it through into the repo
without user intervention is insane. Failures should _always_ be
investigated. Sometimes when I've seen failures on just one arch, it's
actually been a randomly-triggered generic bug. The package-monkey
approach of adding ExcludeArch: and rebuilding will sometimes lead to it
showing up in a different arch, which built before.

If you _really_ want to optimise for the exceedingly rare case of a real
arch-specific bug in a huge package which we're _also_ in a desperate
hurry to release within a matter of hours, then at least make it so that
the ExcludeArch bug can be filed retrospectively in order to allow the
build to 'commit'. Don't let it happen automatically.

-- 
dwmw2