Re: woody Debian Installer plans
Hi Glenn et al,
thanks for your discussion. I will try to address all points that came up in
this single mail.
On Sat, Sep 16, 2000 at 12:36:56PM +1100, Glenn McGrath wrote:
> The way modules will work is that they should only be called (or loaded)
> if needed, so its not a matter of disabling any modules, just only
> calling the modules you need, this is the key to shrinking the installer
> to 1 boot disk (with everything else being fetched as required). There
> may need to be hurd specific alternatives to some modules i guess.
This is probably what I meant, without knowing all the details.
> How important is it for the Hurd to have a native installer?
It is extremely important for our self confidence, but there are other
reasons. Splitting the install like this complicates some things, as we have
seen (configuring PCMCIA once for linux, to install, and once for the
installed OS). There are features in the Hurd which are not easily
supported under Linux (although there is a way to install Hurd translators
from Linux, there is no official, maintained program to do that).
The binaries are incompatible (at least for some time).
Also, it would create a dependency of the Hurd on current Linux
developments. It has happened that Linux ext2 file systems could not be read
by the Hurd because of new, unsupported features, for example. Although in
this case there is an easy work around (and we have catched up anyway), this
can happen again in unexpected ways. This is especially bad because we don't
have enough manpower to follow all developments in all areas (a common
problem for us is that people break compatibility faster than we can verify
that it still works or not). Not relying on a different kernel makes the
individual OS developments more independant.
> Im sure the Hurd users would prefer to not have to depend on "foreign"
> kernels, but is it practical ?
Considering that the differences between Linux and Hurd are quite big, and
we can profit from our own software in the installer and at the same time
removing the dependency on Linux, I think it is the cleaner approach to keep
But note that I am talking about the long term solution. If it turns out
that the obstacles in creating the Linux bootstrapped install are low, we
may settle for that initially.
> The easiest path would be to install hurd packages from a linux based
> installer, i assume most utilities that the installer would use would
> need to be ported to the hurd, to do a native hurd installer. Some
> utilities the new installer will likely be based on are busybox,
> libdetect, libparted, slang.
I see. libparted is something I am interested in working on (I have not seen
the parted source yet, but I realize the need for a partitioning program in
the Hurd). I don't know what busybox is, if it is a slang based dialog
interface, it should be fairly easy to port if it doesn't run already
without changes. libdetect is something we can't make good use of currently:
Either the Hurd runs on your hardware, or it doesn't, there is little
`Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server
Marcus Brinkmann GNU http://www.gnu.org for public PGP Key
Marcus.Brinkmann@ruhr-uni-bochum.de, firstname.lastname@example.org PGP Key ID 36E7CD09