[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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:

	Installer-Menu-Item: nnn

  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
  run again.

  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
  default.

  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):

  Package: install-media
  Installer-Menu-Item: 0
  Depends: retriever
  Description: Configure installation media
  
  Package: floppy-retriever
  Provides: retriever
  
  Package: partitions
  Installer-Menu-Number: 1
  Depends: disk-driver
  Description: Partition disk
  
  Package: disk-driver
  
  Package: format-partitions
  Installer-Menu-Number: 0
  Depends: partitions, disk-driver
  Description: Format and mount partitions
  
  Package: install-base
  Installer-Menu-Number: 0
  Depends: format-partitions, install-media
  Description: Install base system
  
  Package: install-lilo
  Installer-Menu-Number: 0
  Depends: install-base
  Description: Install lilo
  
  Package: rescue-floppy
  Installer-Menu-Number: 2
  Description: Make a rescue floppy
  
  Package: reboot
  Installer-Menu-Number: 3
  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
packages.

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[1]. "Configure the Network" is an item in the main menu, and when it
is selected[2], 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
default.

User picks a card from the menu, and the installer configures that
card's module. This probably involves actually loading up the ethernet
driver.

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

[1] If anyone is confused by this, go read the packaging manual.
[2] Or when something else that needs configured-network is selected.



Reply to: