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

Re: Package variant selection policy using meta packages


Am Sonntag, den 23.12.2012, 22:15 +0100 schrieb Wouter Verhelst:
> No, that's not true; a Recommends is not a Suggests.

That’s not what I said. But it is a suggestion in the sense that
installing a package without the package that is Recommends is valid.

> It seems perfectly suited for your
> purpose. It covers case A perfectly, and B too, with some effort (but
> then, users in class B need to excert some effort anyway; the difference
> is only that now they need to decide which packages not to install when
> installing a -dev package, rather than which packages to install in
> addition to their -dev packages).

I’m still not convinced. What if a user once decided not too care about
-prof package, and not install them, or only some of them every time he
needed them. Now he notices that this is annoying and wants all of them,
for the -dev packages already installed. Recommends does not help him at
all here, as they are taken only into consideration when installing a

With my scheme, he could install i-want-all-prof-packages and the
package manager will automatically install the missing -prof packages.

Another point that has been missed so far: Class B should (probably) be
the default, while class A should be possible. Even if Recommends would
fit A perfectly the wrong variant would be the default.

With meta-packages the approaches would be equally good, and ghc could
have a Depends on i-want-some-prof-packages | i-want-all-prof-package to
hint that the first one should be the default (whether this works should
still be tested).

> It doesn't cover class C

Ignore class C, I’m not sure if that is a demanded use case. OTOH, your
solution is what I proposed, only that it’s only accessible to people
who know equivs.

My original question stands: Is there anything inherently wrong with my
approach, or would it, if I find it the best solution, ok to employ it?
The fact that Recommends might provide some of its features does not
answer that.

Joachim "nomeata" Breitner
Debian Developer
  nomeata@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nomeata@joachim-breitner.de | http://people.debian.org/~nomeata

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: