On Wed, 2007-05-30 at 09:44 -0400, Christopher Aillon wrote: > While it has not happened in a while (my current issues are s390x bound, > not ppc bound) having to do a single rebuild of firefox even to add an > ExcludeArch is a huge loss when trying to get security fixes pushed > where time is critical. If for whatever reason there crops up a c++ > compiler bug on the platform -- and Mozilla will exhibit it as it does > all sorts of funky c++ fu -- delaying the security fix while someone > debugs and fixes the secondary arch problem is not something I'd like to > see as a maintainer, nor something that I imagine we'd like to see in > general as a project. 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). 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? 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? -- dwmw2 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
