Bug#681834: network-manager, gnome, Recommends vs Depends

[Ian Jackson]

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.
    I disagree.

  - 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
    deviation.

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.

Ian.