Re: libc strategy
On Mon, Jul 02, 2001 at 07:45:05PM -0500, GT wrote:
> Ideally, the goal
> would be to make every package compile against BSD libc without
> needing to link in the compat library, but in the mean time we could
> get a real working system up fairly quickly I should think. Frankly,
> I think that should be our first goal.
I've been spending the day playing with this. At a rough guess, about half
of base compiles without too much hassle with the BSD libc (the main
problem is usually having to link against the GNU getopt library). Of the
stuff that doesn't or that I haven't bothered trying, a lot is pretty
pointless - base has a huge stack of bootloaders for every architecture
that aren't terribly relevent to us at the moment. The packages left that
are more "interesting" are:
base-passwd
console-data
console-tools
e2fsprogs (I doubt this is much of an issue - the most important thing
provided by it is fsck. It should probably be replaced
with an analagous package)
elvis-tiny
netbase (Chunks of this ought to be perfectly usable, but it
incorporates the Linux net-tools which are tightly bound
to the kernel. I'd guess that that chunk should be
replaced with the BSD analogues)
procps (Not terribly unexpected. Again most of it probably just
wants to be replaced with the BSD versions)
sysvinit (At the moment I'm using BSD init with somewhat hacked
scripts which force the equivilent of runlevel 2)
util-linux (Again hardly surprising. Again I'd guess that using the
BSD versions would be easier)
libc, ld, etc - these can presumably just be replaced with the BSD
version for now until somebody ports glibc
Other than that, most stuff Just Works(tm). I can't see any real benefit
to using the Linux versions of utilities that interact closely with the
kernel - Debian GNU/Hurd has a different init process and different
methods of dealing with setting up network interfaces to Debian GNU/Linux,
so there's precident for not having a completely identical environment. On
the other hand, I can't see any real advantage of using most of the rest
of the BSD userland - I think it's possible to excuse certain utilities on
the grounds that the kernel is different, but if we're trying to suggest
that Debian is genuinely a kernel-independent OS, I think users should be
allowed to expect that ls (for instance) is going to work in the same way
regardless of whether they're on Debian BSD, Debian Linux or Debian Hurd.
Oh, I had some problems with getting Perl to compile properly - it looks
like there are known issues with it and recent versions of FreeBSD. Since
we're apparantly looking at NetBSD first, this shouldn't be too much of a
problem :) (I just happened to have a FreeBSD machine sitting here, so
rather than reinstall I started to play...)
mjg59@vavatch:/usr/lib$ ssh prometheus
mjg59@prometheus's password:
Last login: Tue Jul 3 01:13:11 2001 from ::ffff:131.111.1
Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD prometheus.jesus.cam.ac.uk 4.3-RELEASE FreeBSD 4.3-RELEASE #0: Sat
Apr i386 unknown
Most of the programs included with the Debian GNU/FreeBSD system are
freely redistributable; the exact distribution terms for each program
are described in the individual files in /usr/doc/*/copyright
Debian GNU/FreeBSD comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
sh: /usr/X11R6/bin/xauth: No such file or directory
mjg59@prometheus:/usr/home/mjg59$
--
Matthew Garrett | mjg59@srcf.ucam.org
Reply to: