Ubuntu Wiki

• Launchpad Entry: https://launchpad.net/distros/ubuntu/+spec/revive-tasksel

• Created: Date(2006-06-08T20:02:21Z) 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 expert mode feature 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.

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.

Scope

Design

General tasksel changes

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

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/tasksel 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.

Implementation

Code

Data preservation and migration

Outstanding issues

BoF agenda and discussion

Raw notes

Ubuntu Server

• add one extra install option (install with task selection)

Use cases (not exhaustive list, just a few examples): Desktop

• Python development task: (XXX FILL in packages)
• Ubuntu development task: (see development section of supported seed?)
• Ubuntu vs. Kubuntu (vs. Edubuntu, Xubuntu?) on netboot installs
• possibly replace some of the dodgy "minimal install" hacks? maybe not though, conflicts with shutting up if only one task is available Remember DVDs; insert DVD and get a choice of all supported tasks for your derivative (makes DVD significantly more useful)

Server

• Plain LAMP server
  • flavors of P covering php, mod_(python|perl), rails?
  • flavors of M covering mysql, postgres
• Zope server ?
• Plain mail server
  • IMAP(S): dovecot, courier
  • POP3(S): dovecot, courier
  • SMTP(TLS): postfix, exim
  • web: no webmail clients in main; potential choices are sqwebmail, squirrelmail for main promotion
  • mailing lists: mailman
  • anti-spam tools: bogofilter

Survey of existing Debian tasks (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):

• metric shedload of language tasks
• database server
• desktop
• DNS server
• file server
• laptop
• mail server
• manual (runs aptitude, probably doesn't actually work at the moment)
• print server
• standard (i.e. priority)
• web server

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

CategorySpec