Re: choice in core infrastructure decisions (Re: Bug#684396: ITP: openrc -- alternative boot mechanism)
- To: email@example.com
- Subject: Re: choice in core infrastructure decisions (Re: Bug#684396: ITP: openrc -- alternative boot mechanism)
- From: Wookey <firstname.lastname@example.org>
- Date: Sun, 2 Sep 2012 03:42:02 +0100
- Message-id: <20120902024201.GZ27622@stoneboat.aleph1.co.uk>
- Mail-followup-to: email@example.com
- In-reply-to: <5025ABC8.firstname.lastname@example.org>
- References: <20120809130307.7498.64495.reportbug@localhost> <20120809135405.GA18318@bongo.bofh.it> <email@example.com> <1344597072.4958.14.camel@tomoyo> <20120810142108.0713ee3d@ileemo> <20120810160956.GB8758@virgil.dodds.net> <20120810215345.GB12900@r500-debian> <firstname.lastname@example.org> <5025ABC8.email@example.com>
+++ Faidon Liambotis [2012-08-11 03:48 +0300]:
> On 08/11/12 01:12, Russ Allbery wrote:
> > There are choices that we don't support because the process of supporting
> > that choice would involve far more work than benefit, and the final goal
> > is excellence, not choice for its own sake. For example, we don't allow
> > users to replace the system C library with a different one. That's
> > something that we *could* do, but the general consensus of the project is
> > that investing our effort in that is not the best way to produce
> > excellence.
> I kind of disagree with that. I don't think that the fact that we don't
> support multiple C libraries is the result of a "consensus decision".
> I think it's just because noone attempted to properly do that and prove
> it's viability and usefulness either to a portion of the userbase or the
> project as a whole.
Not wishing to get into the general argument, but just to clarify that
in fact this (enabling an alternative c-library) has been done in the
past, showing that it is technically possible.
The SLIND project
rebuilt a reasonable subset of debian against uclibc. dpkg has had
support for uclibc-<arch> for some years. It's not actually
technically very difficult, although proper support would involve some
intrusive changes in some places. It would actually be useful to quite
a lot of people if a core subset of Debian was easily buildable for
use with uclibc and busybox, but so far this work has always been done
in forks and derivatives, and not pushed back in, which makes it very
hard to maintain. Deciding whether that was still relevant or worth
the effort would no doubt require another long thread :-)
Steve and Russ have it right. We strive for technical excellence and
the widest functional coverage that can sensibly be achieved in the
context of a binary distro and the available resources. The implies
plenty of choice, but not choice for its own sake.
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM