On Fri, Mar 18, 2005 at 09:35:04PM -0600, Gunnar Wolf wrote: > Frank Küster dijo [Tue, Mar 15, 2005 at 02:15:15PM +0100]: > > This whole argument is bogus. Up to before Vancouver, we always said: > > "A package should be Architecture: any if it can in principle be > > compiled on every arch; the fact that it might not be useful there does > > not justify excluding it from that arch." And AFAIK the rationale for > > this was overall quality of the distribution. > > Now with the requirement for 98% compiled (and N<=2 buildd's being able > > to take the workload) the focus has shifted: From overall quality to > > timely release and quality of individual architectures. > > (...) > Ummm... What do you think about this: > There are packages we recognize will be of little use in certain > architectures - say, KDE on m68k, qemu on a !i386, etc. They should be > built anyway on all architectures where expected to run be buildable, > anyway, as a QA measure - many subtle bugs appear as the result of > architecture-specific quirks. > "Architecture: any" means "build anywhere". We could introduce a > second header, say, Not-deploy-for: or Not-required-for:. This would > mean that KDE _would_ be built for m68k if the buildds are not too > busy doing other stuff, and probably would not enter our archive (or > would enter a different section - just as we now have contrib and > non-free, we could introduce not-useful ;-) ) As pointed out in a recent thread, most of the core hardware portability issues are picked up just by building on "the big three" -- i386, powerpc, amd64. If we know the software isn't going to be used, is it actually useful to build it as a "QA measure"? What value is there, in fact, in checking for bugs that will only be tripped while building software that isn't going to be used? -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature