Re: Package variant selection policy using meta packages
On Sun, Dec 23, 2012 at 10:31:19PM +0100, Joachim Breitner wrote:
> Hi,
>
> 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
> package.
You can easily search for those packages in aptitude, by using the
following search string:
?and(?installed, ?broken-recommends(libghc.*prof$))
Sounds like all you need is just a bit of documentation which explains
that.
> With my scheme, he could install i-want-all-prof-packages and the
> package manager will automatically install the missing -prof packages.
Actually, that's not guaranteed, since your proposed
i-want-all-prof-packages package doesn't actually have any relationship
with the prof packages. As such, removing all haskell packages might be
a correct solution to the problem of "installing this package causes a
shitload of package conflicts" too and might be the solution the package
manager chooses, depending on the packages which are already installed,
the other operations that are being requested at the same time you
install the metapackage, and the phase of the moon.
In the worst case, the correct and wanted solution is 137 "no, not that
one, please calculate the next solution" replies to aptitude away (and
not available if you use another package manager, unless you manually
install all -prof packages, which makes your metapackage useless).
> 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.
Not entirely. I propose a virtual package, you propose a non-virtual
package. Other than that, yes, they are similar, but not quite the same
thing.
> My original question stands: Is there anything inherently wrong with my
> approach,
See above: it doesn't actually solve the problem, it only serves to
confuse the package manager since it's not actually defined what your
weird package relationships mean.
> 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.
I suppose that's true.
--
Copyshops should do vouchers. So that next time some bureaucracy requires you
to mail a form in triplicate, you can mail it just once, add a voucher, and
save on postage.
Reply to: