Re: Glibc-based Debian GNU/KNetBSD
- To: Robert Millan <email@example.com>
- Cc: firstname.lastname@example.org
- Subject: Re: Glibc-based Debian GNU/KNetBSD
- From: Nathan Hawkins <email@example.com>
- Date: Mon, 1 Dec 2003 17:18:29 -0500
- Message-id: <20031201221829.GH4716@quic.net>
- In-reply-to: <20031201214212.GB10867@aragorn>
- References: <20031119202813.GA6625@khazad.dyndns.org> <20031129144515.GA11147@artax.karlin.mff.cuni.cz> <20031129184012.GC19507@quic.net> <20031130021949.GA7065@lightbearer.com> <firstname.lastname@example.org> <20031201011014.GB4716@quic.net> <email@example.com> <20031201123442.GC1237@aragorn> <firstname.lastname@example.org> <20031201214212.GB10867@aragorn>
On Mon, Dec 01, 2003 at 10:42:12PM +0100, Robert Millan wrote:
> On Mon, Dec 01, 2003 at 01:59:49PM -0500, Perry E.Metzger wrote:
> > If you had a list of functional deficiencies in the native libc,
> > though, it would probably be possible to re-implement them and fix
> > them in the native NetBSD libc. NetBSD would like to be maximally
> > compatible with third party apps, so we add stuff we need all the time
> > and are happy to do it. It would also likely be far less work to add a
> > few dozen new functions to libc than for you to re-implement the
> > userland SA framework and debug it.
If I had this much cooperation from FreeBSD, I would never have started
messing with glibc.
> Porting to a Glibc-based from another is kids play. In a few months I
> started two ports and brought them to a stage that took years for a group
> of people to attain.
But glibc isn't fully ported, and until it is, you'll _never_ get to the
stage I already was with the native libc. Glibc will keep everything you
do experimental until enough work is done on it to make it stable.
Also, I'd like to point out to you that when this started, none of the
people involved had any real experience with porting Debian. So that
learning curve, plus RL demands on our time, had a lot to do with the
time it took to accomplish anything. Anyway, I seem to recall that the
critical part of my work on the native libc port got done in about 2-3
The fact of the matter is, we have a choice between an unstable libc
(glibc) and a userspace that mostly just works, or a stable libc and a
userspace that needs lot of minor patches.
glibc didn't fix libtool and configure, nor did it fix packages that
make silly assumptions.
> And I have seen your "less work" patches already. Xfree86 and pam are good
> examples. Have a look at them.
We fixed pam to run on native libc a long time ago. It wasn't that bad,
once I got libshadow written. And last I knew you didn't have an X
server package, which I had on the native libc a long time ago.