PackageSelection

Differences between revisions 1 and 27 (spanning 26 versions)
Revision 1 as of 2005-04-04 18:05:30
Size: 1267
Editor: ca-studio-bsr1o-251
Comment:
Revision 27 as of 2008-08-06 16:26:28
Size: 7536
Editor: localhost
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
= People = ## page was renamed from PackageSelection
##(see the SpecSpec for an explanation)
Line 3: Line 4:
 * ColinWatson
 * MichaelVogt
= PackageSelection =
Line 6: Line 6:
= Goal = == Status ==
Line 8: Line 8:
Improve package selection mechanisms in Ubuntu to improve flexibility
and maintainability
  * Created: <<Date(2005-04-23T09:24:13Z)>> by MattZimmerman<<BR>>
  * Priority: MediumPriority<<BR>>
  * People: MichaelVogtLead, ColinWatsonSecond<<BR>>
  * Contributors: MattZimmerman<<BR>>
  * Interested: MattZimmerman<<BR>>
  * Status: EditedSpecification, DistroSpecification, MattZimmermanQueue[BR]]
  * Packages: <<BR>>
  * Depends: <<BR>>
  * UduSessions: 2<<BR>>
Line 11: Line 18:
= Requirements = == Introduction ==

Improve package selection mechanisms in Ubuntu to improve flexibility and maintainability.

This is '''NOT''' about choosing which packages to install, ship or support, but about the technical mechanisms used to implement these choices.

== Rationale ==

The current approach of selecting more than one package for the end-user is to install meta-packages on the users system that contain dependencies on the packages. `ubuntu-desktop`, for example, depends on `gnome-core` and '''243 other packages.''' This approach has some shortcomings. If a single package that depends on a meta-package is removed, the meta-package is automatically removed as well. Once a meta-package is removed upgrades are hard. The goal is to make sure that the meta-package is always installed (and when it is removed it should reflect a explicit user wish).

== Scope and Use Cases ==
Line 14: Line 31:
 * Consider alternatives and improvements to the existing metapackage
  
mechanism
  * Make it trivial to track additions and removals of packages from the
standard package sets
 * Consider alternatives and improvements to the existing metapackage mechanism
  * Make it trivial to track additions and removals of packages from the standard package sets
Line 20: Line 35:
 * Consider ways to leverage high-level package selections to smooth upgrades
Line 22: Line 36:
= Agenda = == Implementation Plan ==

We should split the current "base" seed into "base" and "standard" seeds. The following packages should move from "base" to "standard":

 * `lvm2`
 * `evms`
 * `evms-ncurses`
 * `mdadm`
 * `parted`
 * `dmsetup`
 * `at`
 * `cpio`
 * `cron`
 * `ed`
 * `fdutils`
 * `file`
 * `hdparm`
 * `info`
 * `logrotate`
 * `man-db`
 * `manpages`
 * `mime-support`
 * `nano`
 * `psmisc`
 * `time`
 * `bind9-host`
 * `dnsutils`
 * `ftp`
 * `iptables`
 * `mutt`
 * `telnet`
 * `ppp`
 * `pppconfig`
 * `pppoeconf`
 * `openssh-client`
 * `rsync`
 * `w3m`
 * `wget`
 * `dmidecode`
 * `lshw`
 * `lsof`
 * `ltrace`
 * `iputils-arping`
 * `iputils-tracepath`
 * `mtr-tiny`
 * `tcpdump`
 * `reportbug`
 * `popularity-contest`


The following packages should be removed by base entirely, because they will be pulled in by dependencies as appropriate:

 * `debconf`
 * `gettext-base`
 * `initrd-tools`
 * `makedev`

The following packages should be moved from base to supported:

 * `netkit-inetd`
 * `mailx` (pending MailRoadmap)
 * `postfix` (pending MailRoadmap)
 * postfix-tls (pending MailRoadmap)

The handling of meta-packages will be handled differently than it is done now. For meta-packages (like ubuntu-desktop), `Recommends` is used to reflect that some packages are "less" important than others. For example, `gnome-core` is certainly a dependency of `ubuntu-desktop` because a non-GNOME system is no longer an Ubuntu desktop system. Some other packages like "ttf-kochi-gothic" (a font package) can be removed while still leaving essentially an Ubuntu desktop system. In order to implement this approach, `apt` should install `Recommends` by default.

`apt` needs to be modified so that it handles meta-packages more efficiently. `apt` should never remove a meta-package as part of a removal of a dependency (e.g. `apt-get remove gnome-core` will ask for the removal of `ubuntu-desktop` now, but in the future it should fail with a message: "to remove 'gnome-core' you need to remove the meta-package 'ubuntu-devel' explicitly). This will require a special field in the `Packages` file (`Meta-Package: yes`).

The "expansion packs" should be done in a similar way to how Debian tasks are done now. However, `apt` should be able to install them directly, and a future AutoMark feature of `apt` (see PackageDependencyManagement) should mark packages installed by a task as part of a task-install.

=== Data Preservation and Migration ===

=== Packages Affected ===

`Apt`, `Synaptic` (for the UI) and the `SeedManagement` software.

=== User Interface Requirements ===

`Apt` and `Synaptic` need to be modified to reflect the new features.

== Outstanding Issues ==

No work in this area has been done yet.

It is not yet clear which set of tasks should be created.

It is not yet clear what the split ubuntu-base packages will be called. A alternative naming would be "ubuntu-base" and "ubuntu-essential", with the advantage that the current "ubuntu-base" package will remain semantically the same.

The following packages are being considered for a move from base to standard, but are less clear:

 * `aptitude` # used by the installer to install the second stage
 * `sudo` # used by the installer for /etc/sudoers
 * `sysklogd` # not ideal for embedders, but we want this running at first reboot?
 * `locales` # big, but important for l10n
 * `vim` # dependency on libgpmg1 could be removed
 * `strace` # terribly useful
 * `ethtool`
 * `mii-diag`

If the "install recommends by default" approach is considered to intrusive, we may alternatively teach `apt` to only install `Recommends` by default for meta-packages.

=== UDU BOF Agenda ===
Line 26: Line 141:
  * Resolve dependencies in debootstrap? (cdebootstrap?)   * Resolve dependencies in debootstrap? (cdebootstrap?) Debian #225947 will probably help us here.
Line 29: Line 144:
   * [https://bugzilla.ubuntu.com/show_bug.cgi?id=4896 Bug#4896]    * [[https://bugzilla.ubuntu.com/show_bug.cgi?id=4896|Bug#4896]]
Line 35: Line 150:
 * Is there a demand for "expansion packs" similar to Debian tasks?
  * Generic server
  * Development - what does it mean?
   * gcc, g++, libc-dev, make, dpkg-dev (build-essential)
   * Be able to build any source package included in the base system (build-essential + build-deps of base)
   * An approximate greatest common factor for building software from source tarballs (build-essential + some subset of -dev packages + autotools)
   * Be able to build any source package included in the selected install (build-essential + build-deps of base/desktop/server/etc.)
   * Some combination of the above
Line 36: Line 159:
= Pre-Work =   * Web server
   * Apache
   * PHP
   * Selection of modules for each (db, auth, mod_{perl,python} ?)
Line 38: Line 164:
 * Review and summarize [https://bugzilla.ubuntu.com/show_bug.cgi?id=4896 Bug#4896] and duplicates === UDU Pre-Work ===

 * Review and summarize [[https://bugzilla.ubuntu.com/show_bug.cgi?id=4896|Bug#4896]] and duplicates
 * Prepare draft package lists for tasks (review Debian tasks, Fedora comps.xml)

== Implementation Status ==

2005-06-17 ColinWatson: AnthonyTowns has changed debootstrap upstream to be able to resolve dependencies and to be able to calculate the whole base system from the Packages file. This is better than what cdebootstrap offers, and I'll switch to this scheme for breezy as soon as I've verified that all our Priority: fields are right. I've modified cdimage to enforce this.

2005-06-27 ColinWatson: Updated breezy's Priority: fields, and switched to the new debootstrap. Done.

PackageSelection

Status

Introduction

Improve package selection mechanisms in Ubuntu to improve flexibility and maintainability.

This is NOT about choosing which packages to install, ship or support, but about the technical mechanisms used to implement these choices.

Rationale

The current approach of selecting more than one package for the end-user is to install meta-packages on the users system that contain dependencies on the packages. ubuntu-desktop, for example, depends on gnome-core and 243 other packages. This approach has some shortcomings. If a single package that depends on a meta-package is removed, the meta-package is automatically removed as well. Once a meta-package is removed upgrades are hard. The goal is to make sure that the meta-package is always installed (and when it is removed it should reflect a explicit user wish).

Scope and Use Cases

  • Avoid hardcoding so many dependencies in debootstrap
  • Consider alternatives and improvements to the existing metapackage mechanism
    • Make it trivial to track additions and removals of packages from the standard package sets
    • Ensure smooth upgrades of systems based on the standard package sets
    • Allow users to express preferences about tracking changes

Implementation Plan

We should split the current "base" seed into "base" and "standard" seeds. The following packages should move from "base" to "standard":

  • lvm2

  • evms

  • evms-ncurses

  • mdadm

  • parted

  • dmsetup

  • at

  • cpio

  • cron

  • ed

  • fdutils

  • file

  • hdparm

  • info

  • logrotate

  • man-db

  • manpages

  • mime-support

  • nano

  • psmisc

  • time

  • bind9-host

  • dnsutils

  • ftp

  • iptables

  • mutt

  • telnet

  • ppp

  • pppconfig

  • pppoeconf

  • openssh-client

  • rsync

  • w3m

  • wget

  • dmidecode

  • lshw

  • lsof

  • ltrace

  • iputils-arping

  • iputils-tracepath

  • mtr-tiny

  • tcpdump

  • reportbug

  • popularity-contest

The following packages should be removed by base entirely, because they will be pulled in by dependencies as appropriate:

  • debconf

  • gettext-base

  • initrd-tools

  • makedev

The following packages should be moved from base to supported:

The handling of meta-packages will be handled differently than it is done now. For meta-packages (like ubuntu-desktop), Recommends is used to reflect that some packages are "less" important than others. For example, gnome-core is certainly a dependency of ubuntu-desktop because a non-GNOME system is no longer an Ubuntu desktop system. Some other packages like "ttf-kochi-gothic" (a font package) can be removed while still leaving essentially an Ubuntu desktop system. In order to implement this approach, apt should install Recommends by default.

apt needs to be modified so that it handles meta-packages more efficiently. apt should never remove a meta-package as part of a removal of a dependency (e.g. apt-get remove gnome-core will ask for the removal of ubuntu-desktop now, but in the future it should fail with a message: "to remove 'gnome-core' you need to remove the meta-package 'ubuntu-devel' explicitly). This will require a special field in the Packages file (Meta-Package: yes).

The "expansion packs" should be done in a similar way to how Debian tasks are done now. However, apt should be able to install them directly, and a future AutoMark feature of apt (see PackageDependencyManagement) should mark packages installed by a task as part of a task-install.

Data Preservation and Migration

Packages Affected

Apt, Synaptic (for the UI) and the SeedManagement software.

User Interface Requirements

Apt and Synaptic need to be modified to reflect the new features.

Outstanding Issues

No work in this area has been done yet.

It is not yet clear which set of tasks should be created.

It is not yet clear what the split ubuntu-base packages will be called. A alternative naming would be "ubuntu-base" and "ubuntu-essential", with the advantage that the current "ubuntu-base" package will remain semantically the same.

The following packages are being considered for a move from base to standard, but are less clear:

  • aptitude # used by the installer to install the second stage

  • sudo # used by the installer for /etc/sudoers

  • sysklogd # not ideal for embedders, but we want this running at first reboot?

  • locales # big, but important for l10n

  • vim # dependency on libgpmg1 could be removed

  • strace # terribly useful

  • ethtool

  • mii-diag

If the "install recommends by default" approach is considered to intrusive, we may alternatively teach apt to only install Recommends by default for meta-packages.

UDU BOF Agenda

  • Simplifying debootstrap maintenance
    • Install a minimal base system, install Ubuntu's "base" on top of it?
    • Resolve dependencies in debootstrap? (cdebootstrap?) Debian #225947 will probably help us here.
  • Tracking package selections
    • Review issues with the current metapackage approach
      • Bug#4896

      • Users want to be able remove some packages, and continue to participate in other transitions
    • Consider solutions
      • Recommends
      • Tasks
      • Other alternatives
  • Is there a demand for "expansion packs" similar to Debian tasks?
    • Generic server
    • Development - what does it mean?
      • gcc, g++, libc-dev, make, dpkg-dev (build-essential)
      • Be able to build any source package included in the base system (build-essential + build-deps of base)
      • An approximate greatest common factor for building software from source tarballs (build-essential + some subset of -dev packages + autotools)
      • Be able to build any source package included in the selected install (build-essential + build-deps of base/desktop/server/etc.)
      • Some combination of the above
    • Web server
      • Apache
      • PHP
      • Selection of modules for each (db, auth, mod_{perl,python} ?)

UDU Pre-Work

  • Review and summarize Bug#4896 and duplicates

  • Prepare draft package lists for tasks (review Debian tasks, Fedora comps.xml)

Implementation Status

2005-06-17 ColinWatson: AnthonyTowns has changed debootstrap upstream to be able to resolve dependencies and to be able to calculate the whole base system from the Packages file. This is better than what cdebootstrap offers, and I'll switch to this scheme for breezy as soon as I've verified that all our Priority: fields are right. I've modified cdimage to enforce this.

2005-06-27 ColinWatson: Updated breezy's Priority: fields, and switched to the new debootstrap. Done.

UbuntuDownUnder/BOFs/PackageSelection (last edited 2008-08-06 16:26:28 by localhost)