Title: Meta-Package debian/control field
DEP: 6
State: REJECTED
Date: 2009-12-20
Drivers: David Paleino <dapal@debian.org>, Luca Bruno <lethalman88@gmail.com>
URL: http://dep.debian.net/deps/dep6
    Source: https://salsa.debian.org/dep-team/deps/-/blob/master/web/deps/dep6.mdwn
License:
 Copying and distribution of this file, with or without modification,
 are permitted in any medium without royalty provided the copyright
 notice and this notice are preserved.
Abstract:
 Introduce the usage of a new field in debian/control, Meta-Package,
 to mark "meta-packages" as such, and allow easy choice of
 installed packages, without being bitten by the "autoremove"
 feature of package management tools.
  1. Introduction
  2. Rationale
  3. Backwards Compatibility
  4. Implementation
  5. Tools support
  6. Changes

Introduction

This document proposes a new field for debian/control, to be used in the so-called "meta-packages". A meta-package is a package which does not contain any files to be installed. Instead it has dependencies to other packages. There are several uses for metapackages, for example to provide a Desktop Environment with some default applications installed.

Rationale

With the autoremove command being now widely used, it can become difficult for a user to install a meta-package except for some packages it depends on.

In fact, when removing any dependency of the meta-package, it gets removed as well, and all other dependencies become leaf packages that autoremove will try to remove from the system. This is usually not what the users want, as they probably installed (or had it by default) the meta-package to have a "standard" environment, but don't want or need specific packages.

With the current situation, the only solution is to specify as manually installed the packages the users want to keep on their systems.

This document thus tries to introduce a new mechanism for meta-packages, which would be marked with Meta-Package: yes in the debian/control control file, and whose dependencies removal would not cause the dependant removal. Think of this as a new Recommends field, which cannot be controlled via /etc/apt/preferences (or similar configuration file).

Backwards Compatibility

We started thinking about "Meta-Depends" fields, but soon abandoned the idea. This is because this field would break existing package managers which haven't implemented yet this DEP. That's why we chose to keep Depends, and add an extra field, called Meta-Package.

Implementation

Packages

Meta-packages should use Meta-Package: yes in a binary stanza in the debian/control file.

Package managers

Package managers, upon removal of any package, should check dependant packages, and act accordingly.

If any dependant package is a meta-package, as defined by this document, it should NOT be removed, opposed to what the current implementations do. The package manager should then add the removed package to a "blacklist" for the dependant meta-package. This allows for upgrades of the meta-package without re-installing everything again, i.e. the package manager should check the dependencies of the meta-package against its blacklist, if present.

If the Meta-Package field is not present, then the package manager should act normally, without any modification from the current behaviour.

If the meta-package is removed, all its dependencies are marked for auto-removal, following the current behaviour.

Blacklist management

Package managers should allow for deletion of the blacklist upon removal of the meta-package.

Moreover, they should allow the deletion of the blacklist, and the installation of the missing meta-package dependencies at the same time.

Tools support

apt-get

None.

aptitude

None.

cupt

None.

smart

None.

Changes