Package Dependency Management

• Launchpad Entry: https://launchpad.net/distros/ubuntu/+spec/dependency-removal

• Created: Date(2005-11-01T18:24:04Z) by MichaelVogt

• Contributors: MichaelVogt, DanielBurrows

• Packages affected: apt, aptitude

Introduction

This specification describes an enhancement to the information the system stores about packages that are installed locally. The goal is to improve the ability of systems to evolve over time to continue to reflect the current Ubuntu release.

These primary improvements are envisaged:

1. The system needs to have some idea why a package was installed. Some of the higher-level package management tools, such as Aptitude, already do something similar to this. They track, for example, whether or not a package was installed because of a specific request by the system administrator, or to satisfy the dependencies of a package that was being installed. This allows them to offer to remove those dependency packages when the chosen package is removed later.

2. Over time, it is inevitable that the Ubuntu team may choose to change the open source products preferred for specific functionality in an Ubuntu system. For example, the Ubuntu developers might choose to migrate from Postfix to Nullmailer, or from Esound to PolypAudio. For new installations that presents no problem, someone installing the new release will simply get the new apps. However, for someone upgrading, it will be necessary to identify whether or not the user has modified any configuration files for the relevant app, and if not, to migrate the system to the new app.

Rationale

Over time, a Linux system accumulates a substantial amount of cruft. Traditionally, installing a package requires installing its dependencies. Later, when that package is upgraded, new dependencies might be introduced and older ones dropped, but in most systems the old package dependencies are never uninstalled. The end result is a plethora of unwanted and un-needed libraries and supporting packages which take up disk space and potentially also slow down the day to day operation of the computer.

These improvements will make it easier to keep Ubuntu systems lean-and-mean over a series of releases, leaving only those packages which the Ubuntu team recommends, the packages explicitly selected by users, and the necessary dependencies required to support those packages.

Scope and Use Cases

The following use cases illustrate the ideas in this spec:

1. Jimmy installed Breezy, and has now updated to the next release. During the update, no matter which package management tool he uses, old dependencies will be removed and new ones installed. There should be no old libraries left on his system once the upgrade is complete.
2. Annabel has installed openldap, and all of its dependencies were automatically installed on her system. Now she is going to remove it from this system using a different package manager. That package manager identifies packages that were installed purely in support of openldap, and offers to remove those too.
3. Jack is upgrading from Breezy to the next Ubuntu release. His system has postfix installed, because that was the default mail server in Breezy, but he has never modified its configuration and so when he does the update, postfix is removed and replaced with newmailer, the Ubuntu team's chosen replacement for postfix in the new release.

Implementation Plan

For the use cases Number 1 the automark feature of aptitude needs to be ported to libapt. It should be easily accessible to all the frontends (apt-get.cc, synaptic, possibly aptitude too).

ScottJamesRemnant: only possibly aptitude? will that not break it?

For the use case 2 the meta-packages/tasks should play a more central role. If a packages was installed as part of a task/meta-package and it is no longer part of that task, it should be removed automatically _if_ the configuration files of that packages are not changed. The "InstalledReason" field should contain "auto, task, manual, unknown".

ScottJamesRemnant: this appears to specify the design, but not the actual implementation. What needs to be changed to do this? How will this affect the installer? How will changes to tasks be tracked, as there isn't explicit data for them? What about packages in two tasks?

Data Preservation and Migration

If the configuration of a automatic dependency was modified we probably do not want to remove that dependency.

Packages Affected

The apt package needs to be improved to provide support for the marking of automatic dependencies. This feature needs to be exported so that frontends like synaptic can make use of it too.

User Interface Requirements

The "apt remove $pkg" needs to be redone so that it suggests to automatically remove the automatically installed packages. Alternativly we can add a "apt-get auto-remove" feature. Synaptic needs to be updated to use this feature too. In the medium term python-apt needs to support it too. Aptitude should make use of the feature as well (use the version in libapt instead of the version in aptitude).

ScottJamesRemnant: please discuss and decide which command to use. What is the scope of python-apt modifications, is that within the dapper timeframe?

Outstanding Issues

A implementation (that needs testing) is available in the michael.vogt@ubuntu.com--2005/apt--auto-mark--0 branch. Close cooperation with the aptitude maintainer is taking place.

The closer meta-package integration is not tackled yet.

Comments

I think an exception should be made for automatically installed packages which have a .desktop file. This to avoid programs from 'magically' dissappearing from the menus when another program is removed. Either not suggest them for removal or have a big warning that you are removing another program. BR (mvo:) this really shouldn't be a issue because stuff that contains .dekstopo files is usually at the top of the dependency chain anyway (TODO: this could be tested with a simple python-apt archive cralwer).

ScottJamesRemnant: is this an outstanding issue? or is this a decision. please move to the appropriate place.