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