On Sat, Apr 26, 2003 at 04:37:16PM +0200, Robert Millan wrote: > On Sat, Apr 26, 2003 at 02:18:05PM +0100, fred@joshua.worldofpain.net wrote: > > Now, relativly early on is probably a good time to decide on a libc to use, > > especially if packages are distributed in binary form. So it guess it boils > > down to do we use the BSD libc and get something working now? Or do we wait > > while glibc and system utils are ported? By something I mean dpkg and apt. > > The vast majority of non system level packages can easily be recompiled for > > BSD libc, I believe, and consequently installed using dpkg and apt. > > that's not true. there's an important quantity of software in Debian that > fails to build on GNU (aka GNU/Hurd), and the problem is merely that > system uses a different _version_ of the same C library. > > now imagine what will break with a BSDish one, i don't think a port with > BSDish library can finish in less than 5 years from now (which is what > the GNU/Hurd port has taken so far) I would beg to differ, based on experience with the NetBSD libc. The things which are required are: 1) Someone who can and will *maintain* the libc package. Said person should also probably be versed enough in build systems to troubleshoot really large and esoteric ones (such as GCC and XFree86), though the latter is not an absolute requirement. 2) A libc that is easily distinguished, has a well known feature set, and which is likely to be found as a special case (if one is necessary) in the upstream code, already. This is, I think, the crucial reason why the NetBSD/i386 port has had far fewer problems than the Hurd/i386 port. Hurd uses glibc with subtle differences (meaning that just detecting glibc isn't enough), most folks aren't aware of how to make use of it's particular feature set (where it differs from Linux), and it isn't highly visible to most of the world (meaning that if special casing is needed, upstream software is less likely to have it). NetBSD, on the contrary, is easily detected (programmatically), it's feature set is reasonably well known and widely documented, and special cases regularly occur in upstream code. In fact, *not* using the native libc would mean that we'd have to check every one of those special cases to see if it was compatible with glibc (ie, is it a NetBSD-only syscall, is it a libc workaround, etc). Also, at least in the NetBSD case, one of the primary reasons to bother (now that Linux is capable of handling so many processors) is that the kernel+libc can be made much smaller, overall, and at certain specific tasks it beats the living snot out of Linux (conversely, Linux has areas where NetBSD falls flat on it's face, in comparison :) Much of the benefit would be lost, if glibc were layered over the top of it, making the port more a matter of curiosity rather than usefulness. -- Joel Baker <fenton@debian.org>
Attachment:
pgpJLWiBw4_Zy.pgp
Description: PGP signature