Launchpad Entry: revive-tasksel
Created: 2006-06-08 by ColinWatson
Contributors: ColinWatson, IvanKrstic, AdamConrad
Packages affected: pkgsel, tasksel
Summary
Re-investigate tasksel for use in our text-mode installer to provide finer-grained package selection.
Rationale
Users often request more fine-grained package selection in the installer. Now that tasksel is much improved from when we decided not to use it for Warty, and now that Ubiquity is available as the simplest installation method, it may be time to consider reviving tasksel as an option in the text-mode installer. To do this, we need to sketch out reasonable subdivisions of our existing seeds as sets of packages that a user might want to install to perform a particular common task, perhaps with reference to the existing Debian tasks; work out how to express these in a reasonable way in our seeds, and transfer this data automatically to tasksel; and resurrect the relevant code in pkgsel.
Note that tasks can be used after installation as well; for example, aptitude supports them, or tasksel can be run later.
ColinWatson actively doesn't want tasksel in ubiquity as standard; it's too much complexity, and adding it in d-i is generally sufficient. (It's possible that derivatives may want it, so in that case we can add it but make it not appear in Ubuntu.) The main target for this specification is the text-mode installer.
These are the existing Debian tasks found in the tasksel package. (Apart from language and "special" tasks, Debian task policy is generally that each task should correspond to a specific thing a user wants to do.)
- lots of language tasks
- database server
- desktop
- DNS server
- file server
- laptop
- mail server
manual (runs aptitude, only usable when running tasksel as a standalone program rather than from d-i)
- print server
- standard (i.e. the priority, which in Ubuntu would correspond to our standard seed)
- web server
Use cases
For the server CD, there are many different sets of packages that one might want to install, but none of them make sense to install by default (since there's no "one size fits all" for servers). At present, we only handle one of these cases (LAMP), and we do so by adding a boot option. It would be nice to be able to deal with this without having to add a boot option for every possibility, since that doesn't scale well and doesn't allow selecting more than one task at once. See UbuntuServerTasks for more discussion on this.
- Mark wants a Python development task now that a number of Python modules have been removed from the default desktop installation.
Developers producing Ubuntu packages would like to be able to install an Ubuntu development task to quickly get a reasonable Ubuntu development system (build-essential, devscripts, fakeroot, pbuilder, bzr, etc.).
System administrators performing Kubuntu (etc.) netboot installations would like to do so without having to know strange runes (the simplest way to do this at present is to boot the installer with preseed/url=http://people.ubuntu.com/~cjwatson/bzr/debian-cd/ubuntu/data/dapper/preseed/kubuntu/kubuntu.seed, which is rather hard to guess).
- Users installing from DVDs should be presented with the ability to install supported tasks from the DVD, which makes it clearer that there was some point in them bothering to download the DVD image rather than the much smaller CD image.
Scope
Technical implementation of tasks. While specific tasks are considered here by way of rationale, this specification only covers the implementation of the task selection mechanism in Ubuntu; UbuntuServerTasks goes into detail on specific tasks for the server edition of Ubuntu.
Design
General tasksel changes
tasksel should keep quiet if only one task is available on the CD, and just install that task; that will preserve current behaviour for our alternate install CDs (unless room is found on those for additional tasks).
We will add a facility to pkgsel to install individual additional packages (mostly a Kickstart requirement, but this has been an occasional user request too).
Task storage
We will store the list of packages for each task in seeds, to ensure that all task packages end up in supported (and thus main/restricted) and to facilitate integration with overrides in the archive (via cron.germinate).
Seeds are derivative-specific (Kubuntu seeds are a bzr branch of Ubuntu seeds, etc.). By contrast, Task fields are both in the Packages file in the archive (which is archive-wide and cannot easily be derivative-specific unless you namespace the task names as in kubuntu-desktop) and used to generate Packages files on each CD/DVD image (which can be derivative-specific). For now, we expect most tasks not to be particularly derivative-specific, as the use cases seem to be mostly server bits and the odd development task, so we will just merge tasks for all derivatives when creating the archive's Packages file and have a loose policy of not putting desktop-specific packages in task seeds for supported derivatives. If derivative-specific options do show up later then we can come up with some way to distinguish their seeds so that the archive can know to namespace their task names.
Add /usr/share/tasksel/ubuntu-tasks.desc to some appropriate package (if all else fails, tasksel itself) with descriptions of each known Ubuntu task. This only needs to be updated when structural changes are made to the list of tasks, not for minor changes to the contents of tasks.
Testing notes
(This section is informative, and technically out of scope for this specification, but will be useful to testers.)
The server CD should offer all tasks with "Task-Section: server" in the header of their seeds. Netboot installations should offer all tasks with any "Task-Section:" header, with the possible valid exception of standard.
BoF agenda and discussion
Discarded ideas, kept for the record
Possibly replace some of the dodgy "minimal install" hacks? Maybe not though, conflicts with shutting up if only one task is available. We just need to make sure that "minimal install" is still expressible by preseeding tasksel/first.
Metapackage debate:
- Should we create metapackages for each task?
Adam suggested doing this so that upgrades are tracked (which is basically why we have ubuntu-desktop et al at the moment)
Colin thinks probably not; huge explosion of metapackages for maybe not a lot of gain and damnit this should be done in the package manager at long last
- there's probably no harm in omitting metapackages for now and deciding this later though