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
Attachment:
pgpyLFhpSJ5KI.pgp
Description: PGP signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
