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?
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 architectures is. > 5. Has any thought been given to supporting the non-i386 ports of > NetBSD? 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 too. -- Matthew Garrett | [EMAIL PROTECTED]
