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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org