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

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



David Paleino <dapal@debian.org> wrote:
[...]
> 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.

I do not understand this, is there a word missing?

[...]
> 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,
[...]

> 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**.
[...]

The current proposal is not backwards compatible since it fundamentally
changes the meaning of Depends. Depends is transitive. If A depends on
B, and B depends on C. A can rely on functionality proveided by C.
Your proposal breaks that, since it allows removal of C (assuming B is
a meta package), keeping it installed in a broken state.

I am not convinced that the gain (easily install KDE without kmail, or
something like that) is worth this price. It changes a clear relation
to something that most of the times works as expected, except for some
special cases.

cu andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


Reply to: