goals for a stable GNU/kFreeBSD release

[Robert Millan]

On Tue, Feb 22, 2005 at 10:40:11PM +0100, Guillem Jover wrote:
> On Tue, Feb 22, 2005 at 07:09:19PM +0100, Robert Millan wrote:
> > I've put together a list of packages that need fixing before we can opt for
> > being candidate to a Debian release.  When this list is reduced to zero, I
> > think we'll have good arguments to convince the Debian community that we're
> > ready (at least for an unstable archive).
> 
> I think ftpmaster requirements are a bit higher than those. Although
> we would be maybe further away from the Hurd for example, but time
> has passed and the requirements are different now.

My impression is that after SCC ftpmaster requirements will lower, but i'm
more worried about fulfilling the community requirements first.

> > Base system as installed by debootstrap:
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > 
> > console-common		- not for us
> > console-data		- not for us
> > console-tools		- not for us
> 
> We need the console counterparts ported from FreeBSD. There's one
> annoying thing, keymaps package name is way generic it should be
> changed to freebsd-keymaps or similar.

Hector ported them, but maybe his patches were lost in friki.  Anyway it
shouldn't be too hard once you know it can't be tested over ssh ;).

I think we should put all userland stuff in a freebsd-utils metapackage.  It's
easier to update the whole thing to a new upstream release/snapshot this way.

However, freebsd-utils is desperately unhappy.  I was working on re-making the
package properly by porting all the source code to Glibc, but since upstream
doesn't have any interest in my portability patches I gave up.  As said before,
I think having Glibc in the ports collection would help in that regard.

Currently we have the following commands in freebsd-utils that can be easily
replaced.  I'm looking forward to those:

  dmesg (Barry wrote a portable replacement, will be merged in sysutils)
  mount (rewrite using libpmount, for sysutils)
  ifconfig (there's one in inetutils, but it doesn't work, see below)
  route (inetutils will eventualy add one, too)

> > dhcp-client		- can of worms (broken due to incompatible ifconfig)
> 
> If we fixed inetutils' ifconfig a bunch of stuff would just work.
> I think it only needs flag support in the command line or similar,
> from what marcus has said several times, the errors and the code.

The detection is in system.{c,h}, which includes system/linux.{c,h}.  The
latter are responsible for setting Linux-style command-line interface but also
for Linux-specific backend options.

There's also the problem that no BSD backend exists at all, but the code could
be ripped from BSD ifconfig.

> > initscripts		- hacked to work with incompatible utils
> 
> I don't recall introducing unportable changes. Did we?

Not in the official package.  But in order to work with different CLI in our
freebsd-utils package we need to maintain these hacks in initscritps (I've
been doing this lately).  Once mount, dmesg and halt are replaced initscripts
will work unmodified.

> > iputils-ping		- not for us (inetutils-ping)
> 
> This should be portable, the only non portable code should be
> the raw packet stuff, that could be splitted in arch specific
> code.

The iputils package contains other, fancier stuff than ping which on first look
seems more unportable.  However, as long as we have inetutils-ping that works
we don't need to worry about this (I mean, not more than we need to worry about
the other 3000 packages that ftbfs).

> > libacl1		- not for us?
> > libattr1		- not for us?
> > libcap1		- not for us
> 
> Those three I think are kernel dependent, would have to read the code
> as well.

acl and attr depend on kernel-specific syscalls.  They're ported to non-Linux
already, and I think kFreeBSD has equivalent (if not even compatible) syscalls
but since packages that use these libs can be easily worked around I didn't
bother to investigate further.  I suspect if you try to use the *BSD interface
you'll stumb on kfreebsd-headers breakage.

As for cap, IIRC it's just a library interface to a Linux module.

> > binutils		- upstream rejected ld.so hack
> 
> What was the reason? Any pointer?

See the thread in:

  http://lists.gnu.org/archive/html/bug-binutils/2004-05/msg00000.html

We should manage to convince upstream that assuming /lib/ld.so is a shared
object on any system is too restrictive.  I think the problem can be easily
reproduced when running a Glibc system under Linux emulation.  Basicaly the
same as on native GNU/kFreeBSD:

  - the kernel refuses to exec ld.so unless it's an executable.
  - hence ld.so is linked as an executable instead of a shared object as usual.
  - libbfd's restrictive checks don't respect this.

> > glibc			- no comment
> 
> Once glibc in debian is unfreezed we can start on this again.

The state in Debian doesn't really matter yet.  We can't do anything wrt the
official Debian package untill the code is merged in upstream (or in a
mergeable state).  However, migrating the sysdeps dir to a newer Glibc version
is a PITA due to:

  - Code that was copied from generic tree to bsd44 tree, which is now
    out-of-sync and is also difficult to identify.
  - breakage in kfreebsd-headers.

> > grub			- or grub2.  whatever that fully works.
> 
> I'd go with grub2, grub legacy has buggy ufs support.

There's also the problem that userspace grub emulator is not write capable.

-- 
 .''`.   Proudly running Debian GNU/kFreeBSD unstable/unreleased (on UFS2+S)
: :' :
`. `'    http://www.debian.org/ports/kfreebsd-gnu
  `-