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

Re: FreeBSD patch for dpkg?

On Sat, Apr 26, 2003 at 10:36:03AM -0600, Joel Baker wrote:
> 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)
> 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).
> 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.

>From what I can see, as these ports are meant to be Debian ported to
*BSD the core of the OS should be as much of *BSD as possible. So the
ports should be using the BSD's libc hacked to work with the Debian
userland. I feel that the Debian/*BSD ports will have more respect if
it's using BSD's libc rather than glibc. As what's the point for porting
Debian to *BSD if it's mainly a GNU core. User take up of the port will
be greater if it's something different from Debian GNU/Linux. And I feel
it'll make Debian more of the Universial OS if these ports use libc. As
if you're wanting the benafits of glibc then the kernel should be Linux
or the HURD.


Reply to: