On Sat, Mar 19, 2005 at 09:52:18AM -0600, Gunnar Wolf wrote: > Steve Langasek dijo [Fri, Mar 18, 2005 at 11:32:08PM -0800]: > > > 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? > As you say, _most_ of the issues are triggered by one of those three > chips, not all. And, by not making a hard requirement to compile the > packages which will not be used, you are not holding the project back > waiting for m68k's KDE. Probably m68k will _never_ compile KDE, as I > doubt their buildds are ever idle - But what do you prefer, say, for > our ia64 buildd, to just sit there waiting for a new package to > arrive, or to start compiling something that will be useful only for > QA, and only probably? But, er, ia64 isn't a slow architecture at all, so there's no reason that the packages being built there wouldn't be usable in the real world -- ia64 should build kde, and then upload it, because it's useful. What was being proposed here, OTOH, was to build packages for architectures where the packages wouldn't be used in the real world due to architecture constraints. I can think of two great reasons not to use random, never-to-be-used packages as a means of doing QA on embedded architectures: it's a waste of electricity, and it doesn't bring a benefit in proportion to the effort. If we find that our toolchains for embedded architectures are weak, then we should certainly try to do better QA on them -- by finding tests that are relevant to the real world, not just by proving that our buildds are heavyweight compilation champions. -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature