Re: redesigning the debian installer
Before I can answer Adam's message, I need to dump out a huge change I
made today to how the main menu works. Before today, Adam would have
flummoxed me with his message, but I seem to be keeping ahead of him. :-)
So here goes..
Each item in the main menu is provided by an installer module. Installer
modules indicate that they want to appear on the menu by including the
following special flag in their control file:
Where nnn is a priority number. The priority number influsences the
ordering of items in the menu; higher numbered items are closer to the
end of the menu. If this field does not appear, a module will not
appear on the main menu.
Dependencies also influence the position of a module in the menu. A module
will never appear before another module which it (directly or indirectly)
depends on. Behaviour of circular dependances is undefined.
The short description of the module is used as the text for its menu item.
When a menu item is selected, the module that provides it is configured if
it is not already configured (ie, if it is just unpacked onto the ramdisk).
If it is already configured, it is reconfigured -- its postinst script is
However, dependencies are honored before this configuration takes place. So
if a module depends on two other modules, and it is selected, both of those
modules will first be installed and configured (if they arn't already).
Note that if a module depends on a virtual package, and more than one
package is available to satisfy that dependancy, and none of them are
configured yet, the installer will generate a submenu listing the candidate
packages and let the user chose which to use. The submenu is generated
and ordered similarly to main menu. (TODO: what do we use for the
title and some help for the submenu?)
The above rules define what the menu looks like and the order of items on it.
There is one other key peice to consider -- the installer has to be able
to pick a reasonable default menu item. To accomplish this, we introduce
a new, special script, that is part of a module's control archive. It's called
the menutest script.
Menutest scripts should return a true value (0) if they think it would be a
good idea if their menu item was default, and a false value if it seems making
their menu item the default would not be a smart decision.
Menutest scripts are optional. If a module does not have one, a simpler
default test is used: if the module is already configured, then it is not
made the default; if it is not configured it is a candidate to be the
Each time, before the menu is displayed, but after it is ordered, the menutest
script of each menu item is run, in turn. The first menutest script to return
a true value makes its menu item the default.
A Menu Example
An example -- we have the following packages unpacked onto the installer's
ramdisk (leaving out the parts of their control files that don't matter):
Description: Configure installation media
Description: Partition disk
Depends: partitions, disk-driver
Description: Format and mount partitions
Depends: format-partitions, install-media
Description: Install base system
Description: Install lilo
Description: Make a rescue floppy
Description: Reboot the system
(Note that the above package and virtual package names are just examples.)
This set of package results in the following menu:
- Configure installation media
- Partition disk
- Format and mount partitions
- Install base system
- Install lilo
- Make a rescue floppy
- Reboot the system
(Here I explain exactly why things are put into the menu in this order.
See doc/ui.txt in cvs if you want to read that.)
It's worth noting that if the user starts up the installer, and picks "install
the base system" as their first step, the following happens:
- install-media-config is configured
- partitions is configured
- format-partitions is configured
- finally, install-base is configured
Adam Di Carlo wrote:
> So this is all micro-dpkg stuff, using Depends/Provides ?
> Clearly you're going to need to arbitrate a set of virtual package
> names for the fundmentals, such as "configured-network".
As you can see above, yes.
> How does this work with attempting to configure your targetted media,
> i.e., IDE, SCSI, NFSRoot, PCMCIA IDE device -- "configured-boot-media"
> and "configured-target-media" virtual pkgs ?
The trick with device detection is that, for example, you might have 10
different packages containing ethernet drivers and all providing
ethernet-driver. configured-network depends on ethernet-driver, but how
do we pick what ethernet driver to use? We want to use hardware
autotodetection, after all. We really need to examine all of those
Well, it works like this. Since all of those packages are available, all
of them are unpacked onto the ram disk. They arn't fully installed yet
though. "Configure the Network" is an item in the main menu, and when it
is selected, the installer looks at its dependancies and sees that they
are satisfied by a slew of virtual packages.
So it makes a submenu of those virtual packages. Just like with the main
menu I described above, their menutest scripts are run to see if they
should be the default item in the menu. Their menutest scripts probably call
the hardware detection code, and if it detects the card, they become the
User picks a card from the menu, and the installer configures that
card's module. This probably involves actually loading up the ethernet
Now that a module that provides ethernet-driver is fully installed,
the network can be set up.
> Please try to keep it simple. I don't want to have to maintain a woody
> boot-floppies. :)
It only _looks_ complicated. :-)
see shy jo
 If anyone is confused by this, go read the packaging manual.
 Or when something else that needs configured-network is selected.