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

Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])

On Sun, Feb 20, 2005 at 10:57:47PM +0000, Dirk Eddelbuettel wrote:
> Clint Byrum <cbyrum <at> spamaps.org> writes:
> > Now, can someone please tell me how messages like the one below, and
> > others, aren't indicative that debian should drop s390, mipsel, and
> > maybe hppa from the list of architectures? How about we release for
> > i386, sparc, and powerpc, and let the others release on their own
> > schedule? This business of supporting 11 architectures and making sure
> > they're all 100% right before releasing is just about the worst idea
> > ever.

> Our chances of actually releasing one day could only increase if we dropped 
> arches such as mipsel, s390, m68k, ... and concentrated on those that actually 
> mattered: i386, powerpc, amd64 -- and I'll gladly add a few more.  But a total of
> eleven is insane.

> But then it doesn't matter anymore. These days, Debian is "infrastructure". 
> We no longer make releases. We provide the basis from which others make releases
> -- Ubuntu, Prodigy, Knoppix, Custom debian dists etc pp.

Any maintainer who believes that trying to release "doesn't matter" is
invited to file serious bugs against all his optional/extra packages so that
the release team can remove them from testing outright rather than worrying
about whether they're in a releasable state.

The more people believe that releasing does not matter, the longer it takes
the rest of us to pull off a release.

> Still, the hours we maste on fixing, building, maintaining, ... code on unused
> platforms is hysterical waste of resources. Resources we don't really have. It
> would be better to concentrate on a core of packages, and platforms, and then
> get on with it.  One day it will break the infrastructure provision, at which 
> point someone will fork our high-priority core packages.

The four most common porting problems for software are endianness (differs
between i386/amd64 and powerpc), word size (differs between i386/powerpc and
amd64), char signedness (differs between i386/amd64 and powerpc), and use of
non-PIC code in shared libs (which is a problem on *all* non-i386
platforms).  A fifth, less significant portability issue involves
arm-specific weirdness with floating point handling, which affects only a
handful of packages that try to do their own direct manipulation of floats.

So which portability problems are the ones that we waste time fixing code

I certainly don't think that maintainers/packages should be penalized for
failures of porters to provide viable build infrastructure for their
architectures, and I think that we should have stricter standards in this
area for etch; but the actual amount of work that maintainers have to do to
their packages that's only of benefit to a single, little-used architecture
is negligible.

Steve Langasek
postmodern programmer

Attachment: signature.asc
Description: Digital signature

Reply to: