[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [RFC] DEP-6: Meta-Package debian/control field



David Paleino wrote:

> Hello people,
> per the DEP process described at http://dep.debian.net/deps/dep0/, this is
> the first call for comments on this proposal.
> 
>         Title: Meta-Package debian/control field
>         DEP: 6
> [..]

Here's the full text, for your convenience:

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 but 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
-------

* 2009-12-20:
  [ dapal ]
  * First draft, RFC made on debian-devel

-- 
 . ''`.   Debian developer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 ----|---- http://snipr.com/qa_page
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174


Reply to: