On Tue, Mar 15, 2005 at 02:15:15PM +0100, Frank Küster wrote: > > I strongly disagree with this. There is a need for a set of base > > packages to work, but it's entirely reasonable to have a release for eg > > m68k without KDE or other large package sets. It's not as if debian/m68k > > would be unusable without KDE packages for example. > 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. The rationale is that setting Architecture: any makes it possible to bootstrap a new port without changing the source package, and there are other ways to cause a package to FTBFS on architectures where it's inappropriate to build it that don't require creating an opt-in architecture list. > For the porters to a specific architecture, this means they have an easy > way to get nearer to the 98% and the N<=2 criteria: Just convince the > maintainers of heavy-loaded desktop stuff, of big self-bootstrapping > numbercrunching applications, and whatever, to take your architecture > out of the Architecture field. Well, it would be better if the porters were making this decision directly and excluding the packages from building, rather than asking the maintainers to mangle the Architecture field; and as long as there were consistent rules being applied when deciding which packages should be excluded on the arch, I don't have a problem with this in principle. So far, this idea doesn't seem to be getting support from the porters, though. > And this is not "cheating". If KDE is of no use on m68k or for most > mips applications; or if 98% of sparc users[1] don't need a desktop, then > it's not unjust if those are simply excluded. Remember, in the old days > before Vancouver ;-) it was mainly compiled for the benefit of the > _other_ arches. I don't think so. If a package builds on 11 out of 12 architectures, it's pretty darn portable. I don't see how getting it to build on the 12th architecture is going to benefit users of the other architectures, since the failure is almost certainly architecture-specific at that point. AFAIK, the rationale for compiling these packages has always been so that they can be *used*; if people are really compiling and uploading binaries that they know will never be used, I'd love to know about it so we can figure out how to put a stop to it and not have to track those binaries for testing. One thing that I know the m68k port has done for us has been to pick up on timestamp skew bugs in autotools-using packages; this benefits us because of the increased precision of filesystem timestamps in 2.6 kernels, which means these build failures are no longer specific to slow architectures. But considering timestamp skew is *still* an ongoing problem in newly-uploaded packages (just like libtool versions too old to work on arm, mips, mipsel; and libraries built w/o -fPIC), I'm not sure how much difference it's made in the long term. > And for the 2% of sparc users that do use KDE, it would probably be okay > to have a separate archive for such stuff. Er, sparc doesn't really have a speed excuse for not building KDE, and I can't imagine excluding a package that's used by 2% of a port's users. I *can* imagine excluding packages that are used by *none* of a port's users. -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature