The interface uses debconf for consistency with the rest of the Debian
installer.
On startup, the tasksel program will read all *.desc files in
/usr/share/tasksel/ for information about what tasks are available. The
tasks will be presented in a simple list selection screen with their short
descriptions.
On exit, tasksel executes the appropriate command to install the selected
packages. If the -t option is given, then tasksel prints out the command
line to use to stdout instead. All other messages are printed to stderr.
To get a new task added to Debian, please file a bug report on tasksel.
Or, create a task package yourself, and then file a bug report on tasksel
for it to be added to tasksel's UI.
Debian derived distributions can add a new .desc file to
/usr/share/tasksel/ to add additional tasks, or modify/divert
debian-tasks.desc to remove tasks.
The file format is a rfc-822 style stanza, with fields named Task, Section
Description (which should include an extended description), Key, Packages,
Enhances, Test-, Relevance, and Parent fields. Here is an example:
Task: graphical-games
Relevance: 9
Parent: games
Section: user
Description: Graphical games
This task provides a variety of graphical games. Old-school unix games are
not included.
Key:
x-window-system-core
Packages: list
quake
myst
monkey-island
The Key field lists packages that are essential to the task. If those
packages are not available, then the task will not be available either. It
need not list all the packages in the task, if some only serve to make it
better when they are available.
The Packages field tells how to get a complete list of packages that are in
the task. In the example above, it uses the "list" method, which is defined
in /usr/lib/tasksel/packages/list. This simple method just lets you list
the packages you want to include in the task in the following lines.
All Key packages will be also be selected for installation when a task is
installed.
In Debian, we have switched to using task packages, so the task files just
list the task packages as Key, and don't list other packages in the task
(instead they are Depends and Recommends of the task package). Another
available method is "standard", which just installs all standard priority
packages, and another is "manual", which, as a special case, runs aptitude
interactively to select what to install.
It's also possible to define other methods, by adding programs to
/usr/lib/tasksel/packages/. Then list the name of the program as the first
word of the task field, and it will be run and passed the name of the task as
its first parameter and any further lines of the task field as its other
parameters, and should output a list of packages in that task. The "list"
method described above is a simple example of such a program.
There is support for automatically installing tasks based on test programs.
If a task has a Test-* field, then a program in /usr/lib/tasksel/tests/
will be run. For example Test-lang fields cause /usr/lib/tasksel/tests/lang
to be run. The test is passed first the name of the task, and then the
contents of the field as parameters. The exit code of the test controls
what to do with the task:
0 - do not display, but do install task
1 - do not display task
2 - display task, marked for installation
3 - display task, not marked for installation
One use of these tests is in automatically selecting a language task
appropriate for the user's locale, and hiding the rest. The lang test
handles this by comparing the value of the Test-lang field of a task with
the locale setting. Tests could also be used for things like automatically
installing hardware support tasks on systems with the right hardware.
There is support for tasks that enhance other tasks. If a task has a
Enhances field, then it should only be installed if all the tasks
listed as in that field are installed. For example, a french-desktop task
enchances a system that has both the french and desktop tasks, and will be
automatically installed on such a system but not others. Such tasks are
hidden from the menu.
If two tasks both enhance the same task, but only one should be selected,
this can be accomplished by adding Test-* fields.
Tasks can be children of a parent task, indicated by using the Parent
field. For example, the desktop task is the parent of gnome-desktop,
kde-desktop, etc. This only controls the display; child tasks are displayed
nested underneath the parent. Only 1 level of nesting is currently
supported. Selecting the parent task does not select any or all of
the child tasks, nor does selecting a child task ensure that the parent
task is installed. Instead, use dependencies between the task packages to
express any such relationships.
If a task is important enough that it should go near the top,
give it a relevance of 1. If a task is not likely to be
used, give it a relevance of 9. Default is 5. Relevance can only be a
single digit.
The Section field is not used by tasksel, but debian-cd currently uses it
to determine if a task is a localization task, or a desktop task, or a
server task.
tasksel also supports preinst, postinst, prerm, and postrm scripts for
tasks. These are run before a task is installed, and after it is removed as
with the dpkg scripts. These scripts sould be installed in
/usr/lib/tasksel/info/, for example, /usr/lib/tasksel/info/desktop.preinst.
Currently they are passed no parameters, but this might change later. These
scripts should take care not to output anything to stdout. You are not
encouraged to use these scripts to install any packages, as in some
situations apt can hang prompting for a CD switch if run from one of these
scripts.
manuel
5e69449641