Re: FreeBSD patch for dpkg?
On Sat, Apr 26, 2003 at 01:36:44PM +0200, Robert Millan wrote:
> On Fri, Apr 25, 2003 at 05:33:58PM -0400, Nathan Hawkins wrote:
> > On Fri, Apr 25, 2003 at 05:13:00PM +0200, Robert Millan wrote:
> >
> > > that's great news!
> >
> > If so, please ask him to use 5.0.
>
> why, is 5.0 the latest version?
Yes. It's a major new release, and has substantial changes. By the time
anything we do is working, FreeBSD 5.1 or 5.2 should be out, and
stabilizing nicely.
Particularly, they rearranged /usr/include/sys, and the changes may
improve the situation with glibc. Or maybe not...
> > I have the workstation now. Just have to find time to sort out which
> > files need to be uploaded. As you can probably imagine, there are
> > several Gigs, and uploading that over dialup is a bit "awkward".
>
> can you put these Gigs on anonymous FTP? then i can select the needed
> files and take only these from your box.
I'll see if I can burn a few CD's. Maybe I can take to a friend's and upload.
> > Not unless a solution can be found for the breakage in /usr/include.
> > With glibc, I am unable to build a _very_ large number of BSD system
> > utilities. I was making some progress, then discovered that _all_
> > networking headers were broken.
>
> if the BSD system utilities are not decently portable software, let's throw
> them away, then.
They're kernel specific. Most of the problems relate to include files,
anyway. There are a few issues with very old BSD functions that aren't
in glibc, and strlcat, but those are relatively easy to fix.
> first of all, i don't think many of these utilities are really _essential_.
> all i can think are essential utilities for a developement system is mount
> and ifconfig. if there are more, please tell them. other convenient utils
> include a fdisk, dmesg and fsck/mkfs.
I'm concerned with a usable _system_. More than a development system.
Also, some of the more problematic ones are programs like FreeBSD's
make, which are required to build the kernel.
> the GNU project is always putting effort into creating portable system
> utilities that can be used on any kernel/libc. it wouldn't be much uncertain
> if a new GNU package included a nice GNU mount and GNU ifconfig that
> know the interfaces of many kernels and autoconf'ed for virtualy any libc
> (there _are_ already a gmount and gifconfig in the GNU OS, they are part
> of the Hurd package as of now and only support Hurd fs servers and pfinet,
> it wouldn't be that hard to add support to it for other system cores.)
And you've really missed an important point here: the system headers in
/usr/include won't compile. Even if I used a nice shiny new GNU
replacement for ifconfig, it won't compile without working headers in
/usr/include/sys and /usr/include/netinet.
The problem is macros and typedef's defined in BSD's <sys/types.h> that
are missing in glibc's. There's a fairly large problem here. Either we
have to fix <sys/types.h> to include all the things that BSD headers
need, or patch all the kernel headers to be compatible with glibc.
Otherwise, they are simply unusable. This goes beyond system utilities,
because most of <netinet/*.h> and all of <netinet6/*.h> are
nonfunctional.
Bruno's strategy seems to have been (I don't know if he's still working
on his port of glibc) to patch all the FreeBSD headers, but I don't like
that approach very much, because it will require constant maintainance.
Getting glibc maintainers to accept large additions into <sys/types.h>
might be problematic, also.
All of this is very messy. I believe I can probably fix the major
headache areas in FreeBSD's libc by adding a few pages of C code, and
making a few one line changes. FreeBSD 5.0 has NSS now, and I think I
can add support for glibc-style /etc/passwd and shadow as an NSS module
in libc. I already have utmpx and getopt fixed, so that was the last
major headache with using native libc.
That's much more maintainable, and much easier to support with limited time and
people.
> for fdisk, we have parted already. for fsck/mkfs there's a portable ext2progs
> package. if we can use ext2fs as the root filesystem, we're ok. otherwise
> we can put together an ufsprogs package. i think it's easier than porting
> all that BSDish code that was never meant to be portable.
We can't use parted yet, it doesn't make partitions and slices right
yet, and doesn't compile. We can't use ext2 as root fs. There are
license conflicts within the kernel, due to the FreeBSD project's
practice of accepting old-style (4-point) BSD licenses. Also, FreeBSD
kernel developers don't seem to pay a lot of attention to supporting
ext2, and I don't believe we can rely on it.
---Nathan
Reply to: