Re: Status of NetBSD port?
On Mon, Jan 19, 2004 at 09:00:05AM -0600, John Goerzen wrote:
> 1. Exactly how much of the NetBSD port comes from NetBSD and how much
> comes from Debian? Is, for example, the NetBSD base system used in its
> entirety, or are only necessary things like ifconfig pulled in from
There's two answers to that. The original port would be based on the
NetBSD kernel and C library. The way I'd envisioned it would be that
base software like ifconfig and mount would be brought in from NetBSD,
with Debian magic wrapping software like ifupdown modified to suit. The
rest of the base system would probably be GNU. Basically, stuff that
needs to know what kernel it's on would be NetBSD except in the cases of
a generic GNU version existing and being used in Debian.
The second effort was started up by Robert Millan and uses glibc. I'm
not clear on how this interacts with stuff that's more tightly bound to
the kernel, but I'd expect it to contain at least as much GNU userland
as the other one.
> 2. Are people actively working on this port?
Ish - I've been somewhat tied up in work, but I've finished that job and
have more free time now. Robert is certainly active on his.
> 3. Where could I best contribute to the port? Would an autobuilder be
> useful? (I do have experience running those; I used to run the one for
> our Alpha port.)
Ha :) An autobuilder would certainly be useful, but currently the main
trick would be installing one. My previous hacked install system isn't
going to be much use at the moment.
> 4. Is there any infrastructure on debian.org machines for this? (Areas
> on sid, etc.) or does one have to use the ucam.org repository?
The ucam.org repository should probably be considered a historical
artifact at this point - I should really lose it and update the website.
"Official" infrastructure is likely to be waiting until the ftpmasters
decide what the best approach to the potential proliferation of
> 5. Has any thought been given to supporting the non-i386 ports of
I did some preliminary work on Alpha and Sparc. It involves a small
amount of toolchain pain, but other than that there didn't seem to be
much that was platform specific. Alpha has the advantage that it
supports hardware that we currently don't - arguably, the improved
NetBSD support for Sun4c (ie, it doesn't suck) would be handy as well. I
believe the subsets of real SGI hardware supported by Linux and NetBSD
are intersecting but don't entirely overlap, so that might be worthwhile
Matthew Garrett | email@example.com