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

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

Andreas Metzler wrote:

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

Probably I didn't use a clear wording.

"[..] to install a meta-package except for some packages it depends on."

Is that clearer?

>> 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 hope no-one ever depends on a meta-package.
Do you have any real case for this?

> I am not convinced that the gain (easily install KDE without kmail, or
> something like that)

Yes, that's exactly the point.

> is worth this price. It changes a clear relation to something that most of
> the times works as expected, except for some special cases.

"Special cases" like depending on a meta-package?
I'd personally change policy to forbid that ;)

Thanks for commenting,

 . ''`.   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: