Re: FreeBSD patch for dpkg?
> can you put these Gigs on anonymous FTP? then i can select the needed
> files and take only these from your box.
> > 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.
> 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.
> 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
I agree that making portable system utilities is a great idea but I am not
sure who/when is able to do it. In my eyes that is a large undertaking. I
think those who are interested should definitly try it though.
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.
I can see on the list archives that similar discussions have taken place
before and that the impediment to using glibc is just lack of time and
resources so a choice has to be made weighing up the benifits of glibc (which,
I, presonally would like to see used) and the advantage of getting the
packaging system working sooner.