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

Re: freebsd-i386 status update



Tollef Fog Heen wrote:
* Nathan Hawkins | Actually, bsdutils, mount and util-linux are built from the same
| source. I've already worked on this, and got the pieces I needed
| working on BSD libc, so I'll probably pick that up again later on.

Having a fdisk-udeb package would be nice for the installer, so ifwhen
you have the time.  Look at bug 156648 for more information (and the
debian-installer module in debian-boot cvs).  I'd like to get
debian-installer working on *BSD as early as possible, so we can weed
out any Linux-centrisism.

Hmm. fdisk in util-linux probably isn't usable. It won't build, and I doubt it can reasonably be made to. Also, I'm not even sure it can create FreeBSD slices and partitions correctly on Linux. I can build FreeBSD fdisk and disklabel, but they're really not well suited to installers. (FreeBSD doesn't use them.)

At the moment, installation has to wait. I'm nearly starting over by going to glibc. (And the unstable and incomplete state of glibc doesn't help. Right now, I can't even make a package of it.) I have problems with gcc and binutils also, so getting those issues fixed are a higher priority right now.

That said, I browsed through the CVS tree, and I do have a few comments:
* Busybox is going to be a lot of work to port to *BSD. Quite possibly one of the hardest packages I've seen. 8-( * Anything to do with device detection and network configuration will probably be different. At the least, device names will likely be different. Ethernet interfaces won't all begin with eth. * Almost anything that looks at /proc won't work. It would be a good idea to avoid that in code that is intended to be common to all archs. * I would suggest processing the lists of udeb's in build/pkg-lists with cpp or m4. That would allow you to use #include or whatever m4 calls it. That way, the list of udeb's for linux archs could use #include linux-common, while BSD ports could do something else. Also would take care of comments, and allow use of macros for things like kernel flavours.

| This is really to do with the fact that Debian is going to have to
| change its essential package list at some point. At present, there are
| too many things that assume Linux.

We already do that for the Hurd and the various arches, I doubt *BSD
will be much different.  (libc6 is libc6.1 on alpha and ia64, iirc.)
please submit wishlist patches against debootstrap.

I believe that mount will be a different package, and possibly util-linux will need to be as well. Much of it not only doesn't compile, but also is too Linux-specific to be worth porting.

	---Nathan



Reply to: