Re: redesigning the debian installer
Adam Di Carlo wrote:
> Some generalized comments and musings.
>
> Modularization is specified for retrievers but I fail to see how that
> is going to address, say, installation over the network for i386 boxes
> (providing perhaps modules for NIC cards) or installation via pcmcia
> on arches that support that (which should be i386, alpha, and sparc, I
> think, dunno really about sparc/powerpc).
I never said this was a complete design yet. You're right, these are
all gaping holes:
> I believe there must be a module subsystem defined for not just
> retrieval issues, but also:
>
> - network/hardware support (discussed above)
>
> - network configuration (dhcp/bootp)
>
> - target media support (what we're installing to -- this means
> PCMCIA/IDE devices, NFSRoot, RAID boot/root, etc.)
(And in my TODO list now.)
The reason I specced out retreivers first is that they are a pretty
simple, and yet essential part of the design, and they are one of the
few classes of modules that need to present a standard command-line
interface.
The way network hardware support, network configuration, and target
media support all work, in general, is:
- A module's maintainer decides it needs one of these things (a configured
network, say).
- They make the module depend on an appropriate virtual package
(configured-network).
- Before the module is used, the system makes sure its dependencies are
met, and that the modules that satisfy those dependencies are
configured (so the network is configured, but first hardware support
for it is set up).
(I need to change how the main menu works a little bit, come to think
of it. More on this soon.)
My point is that these various classes of modules don't need to be
specified in much detail. I don't care how a network configuration
module works, or what programs it installs where, as long as once it
is set up, there is a configured network.
Of course, that's just in general -- we do need to think about each of
these classes of modules and find the little details that need to be
specified.
> I think you need to specify a TFTP retriever, but not really sure.
> The network retrievers should be centered around the "best of breed"
> tiny net clients, such as snarf or busybox's wget.
Implementation details IMHO.
> Hardware detection should be *designed* for modern hardware, perhaps
> having also support for older stuff. I'm saying you should be
> targetting PCI busses or OpenFirmware where supported. You'll get
> better milage that way. I'm not saying rule out ISA or other legacy
> support necessarily, however -- just that it should be a sideline.
I agree.
> Also, I reiterate that we need to liase with the larger linux/GNU
> community regarding either the adoption or enlargement of current
> hardware detection subsystems (i.e., libdetect if that's what we use).
Clearly. Interestingly, libdetect is used by mandrake, and also includes
code from redhat (not sure if redhat uses it directly). I still want to
look at other similar libraries, but I think that having several
distributions use the same hardware detection code is a good thing.
I wish we could share more, it's really silly we all go off and write
our own installers. Um. Er.
> I think more needs to be specified regarding automated installation,
> which is a big issue as discussion here has shown. I guess that would
> be in the context of the debconf-tiny ? I suggest the retrievers
> could be purposed to retrieve also configuration files, perhaps
> specified in RFC 822 or XML format.
Right that's doable easily (trivial to map debconf db to 822-format) and
will work fine. Or there is this mythical debconf remote database stuff
that maybe one day someone will actually write.
--
see shy jo
--
To UNSUBSCRIBE, email to debian-boot-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: