Bug#681834: network-manager, gnome, Recommends vs Depends
Bdale Garbee writes ("Bug#681834: network-manager, gnome, Recommends vs Depends"):
> I believe our goal should be to require that there not be a hard Depends
> relationship. I would be equally satisfied if the dependency were just
> dropped, or if it were possible to craft a suitable "or" list of
> alternatives that network-manager could be the first choice of the
> maintainer among. I have not followed the discussion closely enough or
> independently studied this situation in sufficient detail to know if
> this is possible, however.
Thinking about this some more, I think it would be better to mandate
a specific solution.
There have been many suggestions of alternative approaches which are
(i) more complicated and (ii) whose effects we are not entirely sure
and (iii) which would require specifying in detail, but which somehow
avoid sidestep the key disputes.
The key disputes seem to be:
- Some people claim that metapackages should not use Recommends.
- GNOME upstream have declared Network Manager to be an integral
part of GNOME and the Debian maintainer is insisting on following
their lead in gnome-core. The maintainer is essentially asserting
that the very purpose of the gnome-core metapackage is to reflect
precisely what upstream have decreed, and that we should not
deviate. I disagree; I think (a) we should feel free to deviate
from upstream if doing so is better for our users and (b) anyway
setting one of the dependencies to Recommends is not a significant
My best argument in favour of specifying the specific solution is that
we know exactly what the effects will be.
If we want instead to write a resolution specify the effects, we will
have to consider carefully exactly which effects we want to mandate.
For example, creating another metapackage might have transitional
implications; both for users upgrading from squeeze and for other
packages which depend on gnome-core.
Also if we want this to be in wheezy we want not to be messing about
with complicated solutions. There is a risk, for example, that the
maintainer might choose an approach unsuitable for release in wheezy.
We can hardly tell the maintainer `you must do this but you must do it
in the way you think is best for wheezy' - that would amount to asking
them to undermine their own judgement.
For the same reason I would like a decision quickly.