On Sun, Jan 12, 2003 at 01:15:47AM -0600, Georg Lehner wrote: > However, I am not at all familiar with the internals of the installers, > I just use them a lot, also, real live will kick in at last next > wednesday and who knows if I'll get left time to breath.
Well, it's certainly less work to learn the internals of an existing installer and port it than to do it from scratch. In both cases you have to become intimate with the internal details, in the former it's just easier to figure it out. > What also strikes me is the fact, that parts of the configuration will > be similar on Linux/Hurd machines, so it seems reasonable to do this > configuration only once, whenever possible and take the data for the > other installation. This is even more true for several GNU/Linux machines, and a completely orthogonal issue. Whatever is uses to do this among several GNU/Linux systems could possibly be extended to also be applicable on a heterogenous network. > a) the system installation process should work (in Debian/GNU/Hurd) > > b) How the boot scripts should work (in Debian/GNU/Hurd) > > ad a) While Hurd and Linux behave almost the same once they are > installed I doubt that the installation is very similar. Fundamental > bits are different It's absolutely similar. The differences are marginal. > filesystem mounting Although the actual command to do this might be distinct (even though we have a wrapper script), which partitions have to be mounted where and when is completely identical (except for minor nits like /usr). > init process/runlevels That's something that is not yet solved to our satisfaction, but Debian has an abstraction for that (update-rc.d) that has the potential to hide all differences relevant for Debian. > obtaining hardware/system information Except for the fact that there is not much to detect that the Hurd actually supports, there is nothing that should be different. If there are differences in how to access the hardware at probing etc, then they should be completely hidden in the hardware detection libraries, which of course should be ported from the GNU/Linux to the GNU/Hurd system. > So decisions have to be made, to which point Debian/Hurd will try to > emulate Debian/Linux behaviour, and from where on Hurd specific > features will be favoured. Certainly, and there are probably things that can be done to exploit Hurd specific features in the installer. However, just to get something that works, doing a minimal port of the Debian GNU/Linux installer is the best way to go. > ad b) I have read some discussions about this. Personally I use > daemontools which is not standard in Linux. I like runit, but this > is all matter of personal taste. Wether integration of lots of > packets is make easier or even possible depends on the choice of > system V init. But more important even: To make worth the effort of > _any_ package porting a decision has to be made: _any_ decision. The decision for Debian GNU/Hurd has always been to be like Debian GNU/Linux where it isn't against some fundamental principle of the GNU/Hurd, and where conflicts arise they are solved at the apprioriate level. I think in general the proof has to be made the other way round: If you have to divert from what is already implemented in other systems like GNU/Linux or BSD, you need to provide good reasons why you think it is worth the effort to divert and redo it. Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org [EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
