For your consideration: Secondary Architectures in Fedora

Jesse Keating jkeating at
Wed May 30 14:43:27 UTC 2007

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.

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

> If so, then I suppose it would be possible to allow retrospective filing
> of ExcludeArch bugs, to allow partially-failed builds to 'commit'
> despite the fact that the ExcludeArch: in the archived src.rpm wouldn't
> match reality. That would save you the amount of time it takes to put
> the package through the build system for a second time. But is it really
> worth it?

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

Jesse Keating
Release Engineer: Fedora
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <>

More information about the fedora-devel-list mailing list