| 1 |
dapal |
136 |
[[!meta title="DEP-6: Meta-Package debian/control field"]] |
| 2 |
|
|
|
| 3 |
|
|
Title: Meta-Package debian/control field |
| 4 |
|
|
DEP: 6 |
| 5 |
|
|
State: DRAFT |
| 6 |
|
|
Date: 2009-12-20 |
| 7 |
|
|
Drivers: David Paleino <dapal@debian.org>, Luca Bruno <lethalman88@gmail.com> |
| 8 |
|
|
URL: http://dep.debian.net/deps/dep6 |
| 9 |
|
|
License: |
| 10 |
|
|
Copying and distribution of this file, with or without modification, |
| 11 |
|
|
are permitted in any medium without royalty provided the copyright |
| 12 |
|
|
notice and this notice are preserved. |
| 13 |
|
|
Abstract: |
| 14 |
|
|
Introduce the usage of a new field in debian/control, Meta-Package, |
| 15 |
|
|
to mark "meta-packages" as such, and allow easy choice of |
| 16 |
|
|
installed packages, without being bitten by the "autoremove" |
| 17 |
|
|
feature of package management tools. |
| 18 |
|
|
|
| 19 |
|
|
[[!toc ]] |
| 20 |
|
|
|
| 21 |
dapal |
138 |
Introduction |
| 22 |
|
|
------------ |
| 23 |
dapal |
136 |
This document proposes a new field for debian/control, to be used in |
| 24 |
|
|
the so-called "meta-packages". A meta-package is a package which does |
| 25 |
|
|
not contain any files to be installed. Instead it has dependencies to |
| 26 |
|
|
other packages. There are several uses for metapackages, for example |
| 27 |
|
|
to provide a Desktop Environment with some default applications |
| 28 |
|
|
installed. |
| 29 |
|
|
|
| 30 |
dapal |
138 |
Rationale |
| 31 |
|
|
--------- |
| 32 |
dapal |
136 |
With the *autoremove* command being now widely used, it can become |
| 33 |
dapal |
140 |
difficult for a user to install a meta-package except for some packages it |
| 34 |
dapal |
136 |
depends on. |
| 35 |
|
|
|
| 36 |
|
|
In fact, when removing any dependency of the meta-package, it gets |
| 37 |
|
|
removed as well, and all other dependencies become *leaf packages* that |
| 38 |
|
|
autoremove will try to remove from the system. This is usually not |
| 39 |
dapal |
137 |
what the users want, as they probably installed (or had it by default) |
| 40 |
|
|
the meta-package to have a "standard" environment, but don't want or |
| 41 |
dapal |
136 |
need specific packages. |
| 42 |
|
|
|
| 43 |
|
|
With the current situation, the only solution is to specify as |
| 44 |
dapal |
137 |
*manually installed* the packages the users want to keep on their |
| 45 |
|
|
systems. |
| 46 |
dapal |
136 |
|
| 47 |
|
|
This document thus tries to introduce a new mechanism for |
| 48 |
|
|
meta-packages, which would be marked with **Meta-Package: yes** in the |
| 49 |
|
|
debian/control control file, and whose dependencies removal would not |
| 50 |
|
|
cause the dependant removal. Think of this as a new Recommends field, |
| 51 |
|
|
which cannot be controlled via /etc/apt/preferences (or similar |
| 52 |
|
|
configuration file). |
| 53 |
|
|
|
| 54 |
dapal |
138 |
Backwards Compatibility |
| 55 |
|
|
----------------------- |
| 56 |
dapal |
136 |
We started thinking about "Meta-Depends" fields, but soon abandoned the |
| 57 |
|
|
idea. This is because this field would break existing package managers |
| 58 |
|
|
which haven't implemented yet this DEP. That's why we chose to keep |
| 59 |
|
|
Depends, and add an extra field, called **Meta-Package**. |
| 60 |
|
|
|
| 61 |
dapal |
138 |
Implementation |
| 62 |
|
|
-------------- |
| 63 |
|
|
### Packages ### |
| 64 |
dapal |
136 |
Meta-packages should use **Meta-Package: yes** in a binary stanza in the |
| 65 |
|
|
*debian/control* file. |
| 66 |
|
|
|
| 67 |
dapal |
138 |
### Package managers ### |
| 68 |
dapal |
136 |
Package managers, upon removal of any package, should check dependant |
| 69 |
|
|
packages, and act accordingly. |
| 70 |
|
|
|
| 71 |
|
|
If any dependant package is a meta-package, as defined by this |
| 72 |
|
|
document, it should **NOT** be removed, opposed to what the current |
| 73 |
|
|
implementations do. The package manager should then add the removed |
| 74 |
|
|
package to a "blacklist" for the dependant meta-package. This allows |
| 75 |
|
|
for upgrades of the meta-package without re-installing everything again, |
| 76 |
|
|
i.e. the package manager should check the dependencies of the |
| 77 |
|
|
meta-package against its blacklist, if present. |
| 78 |
|
|
|
| 79 |
|
|
If the Meta-Package field is not present, then the package manager |
| 80 |
|
|
should act normally, without any modification from the current |
| 81 |
|
|
behaviour. |
| 82 |
|
|
|
| 83 |
|
|
If the meta-package is removed, all its dependencies are marked for |
| 84 |
|
|
auto-removal, following the current behaviour. |
| 85 |
|
|
|
| 86 |
dapal |
138 |
#### Blacklist management #### |
| 87 |
dapal |
136 |
Package managers should allow for deletion of the blacklist upon |
| 88 |
|
|
removal of the meta-package. |
| 89 |
|
|
|
| 90 |
|
|
Moreover, they should allow the deletion of the blacklist, and the |
| 91 |
|
|
installation of the missing meta-package dependencies at the same time. |
| 92 |
|
|
|
| 93 |
dapal |
138 |
Tools support |
| 94 |
|
|
------------- |
| 95 |
|
|
### apt-get ### |
| 96 |
dapal |
136 |
None. |
| 97 |
|
|
|
| 98 |
dapal |
138 |
### aptitude ### |
| 99 |
dapal |
136 |
None. |
| 100 |
|
|
|
| 101 |
dapal |
138 |
### cupt ### |
| 102 |
dapal |
136 |
None. |
| 103 |
|
|
|
| 104 |
dapal |
138 |
### smart ### |
| 105 |
dapal |
136 |
None. |
| 106 |
dapal |
138 |
|
| 107 |
|
|
Changes |
| 108 |
|
|
------- |
| 109 |
|
|
|
| 110 |
|
|
* 2009-12-20: |
| 111 |
|
|
[ dapal ] |
| 112 |
|
|
* First draft, RFC made on debian-devel |
Parent Directory
| 
Revision Log