ReviveTasksel

Revision 3 as of 2006-06-21 10:21:34

Clear message

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

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)

Tasksel general

  • colin actively doesn't want tasksel in ubiquity; too much complexity, and can be added in d-i instead
    • derivatives? might want tasksel, which would warrant adding it, and having it not appear in ubuntu
  • d-i implementation: shut up if only one task is available on the CD

NOTE: tasks will not include non-main/restricted packages for obvious support reasons.

Task implementation:

  • use seeds to ensure that all task packages end up in supported, integrates properly with rest of archive
  • seeds are derivative-specific (Kubuntu seeds are a branch of Ubuntu seeds, etc.)
  • Task: fields are (a) in the Packages file in the archive (archive-wide, not derivative-specific) and (b) used to generate Packages files on each CD/DVD image (derivative-specific)
  • propose merging tasks for all derivatives when creating archive's Packages file, and having a loose policy of not putting particularly desktop-specific stuff in task seeds for supported derivatives
  • most tasks for the time being ought to be not particularly derivative-specific (the use cases seem to be mostly server bits and the odd development task); if derivative-specific options do show up later then we can maybe come up with some way to idistinguish them in the seeds

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
  • 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 Smile :-)

  • there's probably no harm in omitting metapackages for now and deciding this later though


CategorySpec