from cvs.debian.org
>
> The Installer UI
> ----------------
>
[snip]
>
> After the kernel boots up, the first thing the user will see is whatever UI
> is being used, configuring itself. This is equivalent to the current
> installer asking if the screen supports color, and keyboard configuration.
i'd prefer to choose the ui before proceed with any other step
> It might also include language selection, mouse setup, etc. All up the
> individual UI. [ Language selection may do better as a seperate module and
> step, though. ]
>
> Once the UI is configured, the user will see a list of every step in the
> install process, with a proposed next step, and an alternate next step, at
> the top. This is very similar to how the installer works now. We have
> observed that this layout gives the user a great deal of flexibility, which
> is very useful if something goes wrong and they have to run steps out of
> order for some reason, or repeat a step. However, we also anticipate that
> people might not want to see this menu, and would rather go through a
<strong>people might not want to see this menu</strong>
> rigidly linear install process. Therefore, this menu will be a debconf
> question asked at priority "medium", and so it might not actually be
> displayed.
>
priority: low (debian maniacs)
medium (advanced users)
high (default)
critical (distribution reviewers :) )
pre-answered (laboratory administrators and the like)
[snip]
>
> Implementation
> --------------
>
> If only one UI is available on the install media, it will automatically be
> used. If more than one UI is available, they will be prioritized, and each
> will be configured. If one fails to configure, the next on the list is tried,
> until one succeeds.
>
i'm already seeing my monitor that flickers without any control :)
> UI's will be impelemnted as some kind of loadable module for the debconf
> implementation used by the installer. Implementation to be determined.
>
> 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.
>
might other modules, maybe wanting to be showed in the manu, depend on this
kind of packages? is it reasonable to think such a need? this would brake
the ordering scheme.
> 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.
the long description of the module is the and extensive help a user might
request in order to better understand what is going on.
>
> 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?)
if the virtual *module* is named ui_something.deb the help hint and the detailed
help could be from ui-help_something.deb which, implicitly, any package providing
*that* virtual module will depend on.
>
> 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
>
> To understand why, order all the modules by their Installer-Menu-Number's:
>
> install-media (0)
> format-partitions (0) Depends: partitions
> install-base (0) Depends: format-partitions, install-media
> install-lilo (0) Depends: install-base
> partitions (1)
> rescue-floppy (2)
> reboot (3)
>
> I've listed any dependencies on other modules that show up on the menu. In
> each such case, they have to show up before the item that depends on them.
> So partitions has to appear before format-partitions, which has to appear
> before install-base. And install-media also has to appear before
> install-base. And install-lilo has to appear after install-base. And that's it,
> with those dependancies ordered properly, we have the menu order shown above.
>
> 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
>
-----[ Domenico Andreoli, aka cavok
--[ get my public gpg key at http://www.freeweb.org/free/cavok/gpgkey.asc
-----[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
Attachment:
pgpyxbP45i5Ce.pgp
Description: PGP signature