Re: questions about debian/hurd...
On Sun, May 29, 2005 at 01:43:13PM +1200, Philip Charles wrote:
> On Thu, 26 May 2005, Michael Banck wrote:
> > However, porting any of base-config, debootstrap and debian-installer
> > will get us nearer to a native Debian GNU/Hurd install, with the
> > possible intermediate step of booting d-i from GNU/Linux,
> > cross-debootstrapping hurd-i386 from it and then running base-config
> > after booting into the Hurd.
>
> Once sarge is released could we get the d-i team to start looking at
> incorporating Debian GNU/Hurd into the installer?
I'm one of the d-i hackers and I've been working on this for the last
week or so already, although I had been hoping to announce that fact
only once I actually had something that worked. :-) I've got untested
patches to the build system, rootskel, and base-installer; I've made
libdebian-installer build, and uploaded quite a few binaries from the
dependency tree above that; I've made some progress on netcfg; and I've
got a hit-list of other Linux assumptions I know about that we need to
iron out. Once I have an installer image that boots at all, I may be
able to get one or two other d-i developers interested in helping out.
If people want to help out before that, a debootstrap port which can
build a Hurd chroot from a Hurd system would help; basically, take the
modifications made to debootstrap's 'functions' file in crosshurd which
work around the lack of passive translator support in tar, port them
back up to current debootstrap, and make them be used only when
installing Debian architectures matching hurd-* so that the patch has a
chance of being incorporated into the Debian debootstrap package.
It would also be useful to have gnumach-udeb and hurd-udeb, please. They
should have pretty much the same contents as their .deb equivalents,
but:
* Build-depend on debhelper (>= 4.2.0) and put XC-Package-Type: udeb
in the udeb binary stanzas in debian/control; that will make
debhelper skip documentation, most maintainer scripts, etc.
* Don't bother with a hurd-udeb.postinst; it won't get run anyway.
* I think you can drop at least /hurd/fakeroot, /hurd/hello,
/hurd/hello-mt, /sbin/nfsd, /bin/fakeauth, /bin/fakeroot-hurd,
/bin/timertest, /bin/fstests, and everything in /etc. We may want to
reduce it further or split it up later.
* Drop the Essential: yes flag and the sysv-rc dependency from
hurd-udeb.
* If you're delivering gnumach-udeb on i386, make sure that its
priority is no higher than optional. Apart from that, the priority
isn't important for either package.
A native first-stage installer should not require the native-install
script; that should all be set up by debootstrap. I think it's OK to
concentrate entirely on native installation in d-i, and leave the
cross-installation to crosshurd et al; native installation is a better
long-term strategy anyway, since for example the installer won't offer
you the chance to set up network interfaces that are unsupported by the
Hurd.
I don't think base-config should require any more than trivial porting
(e.g. disabling Linux-specific keyboard configuration, some
Linux-specific parts of hostname configuration, etc.). That won't really
be interesting until later on.
Cheers,
--
Colin Watson [cjwatson@debian.org]
Reply to: