Re: Cross installation package
- To: Georg Lehner <Jorge.Lehner@gmx.net>
- Cc: Lista Hurd <firstname.lastname@example.org>
- Subject: Re: Cross installation package
- From: Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>
- Date: Sun, 12 Jan 2003 12:31:40 +0100
- Message-id: <20030112113140.GB16335@ulysses>
- In-reply-to: <1042355747.1346.99.camel@toa>
- References: <1042317367.1345.28.camel@toa> <20030112000625.GB3391@ulysses> <1042355747.1346.99.camel@toa>
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
> 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.
`Rhubarb is no Egyptian god.' GNU http://www.gnu.org email@example.com
Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/