[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: The 98% and N<=2 criteria (was: Vancouver meeting - clarifications)

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

> 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

Reply to: