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

Re: FreeBSD patch for dpkg?

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

Reply to: