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

Re: Glibc and NetBSD



These are opinions, not proven facts.

It is not yet entirely clear what the whole situation with glibc will be. I am working with it on FreeBSD, but have by no means decided for or against it yet. I am still assessing it. This is what I have found so far:

Pros
* Makes a dramatic difference in the number and invasiveness of patches needed to make Debian packages build. * utmp, shadow passwords, and wide character support cease to be problems. The utmp code seems to be working well now, but I have never been completely happy with the libshadow I wrote.

Cons
* glibc is not really completely ported to FreeBSD, and probably even less completely ported to NetBSD. It is definitely immature, with a resulting loss of stability. * glibc may need substantial ongoing work to work correctly with the BSD kernels. Certainly things like threads and signal handling may take major work to get working as well as native libc. What other things of this sort are we going to find? * Breaks BSD sources. This is the part I have a problem with. Currently, I cannot build most of the FreeBSD utilities and libraries that I use. This is unacceptable, and a solution must be found for this, or glibc isn't usable.


How much work is it to make the BSD sources work with glibc, and glibc work well with them, and is it actually less work than patching Debian packages to run with the BSD libc? This may boil down further to a question of whether it is better to make a small number of large changes to a small amount of code, or a large number of small changes to a lot of code, spread over a lot of source packages.

I think that it is too soon to say. First let's see how it goes, and suspend judgement for or against until it is clearer what all will be required.

	---Nathan

Robert Millan wrote:
On Tue, Jul 23, 2002 at 12:50:43PM -0700, Michael Goetze wrote:

I have a sufficiently working glibc that I can build binutils and gcc
against it and then use them to rebuild a working glibc, but it'll need
some work yet before it's even vaguely production ready. The general
opinion at Debconf seemed to be that going with glibc was preferable to
using BSD libc - does anyone have any comments?

I'm pretty sure I've said this before, but here I go again... I think the C
library is one of the features Debian people would want to use Debian */*BSD
for, due to it's various real or perceived advantages. I'd bet that 90% of the
people screaming at you to use glibc are going to go on using just Debian
GNU/Linux either way...


Debian has 9000 packages now, and all them are proven to build with the
kernel Linux and the GNU libc. Some are also proven to work with the GNU
Hurd and the GNU libc. Very few are proven to work with the *BSD kernels
and the *BSD libcs.

Basicaly, taking to use a BSDish libc would (at least) triplicate the effort
necessary for building a GNU/*BSD distribution. What kind of advantages
does the BSD libc's have to justify such effort increment?




--
To UNSUBSCRIBE, email to debian-bsd-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org



Reply to: