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

about ui of the installation



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: pgp3zV5kqtCZ0.pgp
Description: PGP signature


Reply to: