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

[Ian Jackson]

Sune Vuorela writes ("Bug#681834: network-manager, gnome, Recommends vs Depends"):
> Metapackages is *someones* *subjective* opinion what a specific set
> should do.  And this subjective opinion is up to the maintainer to
> figure it out. Not anyone else.

I don't agree with this as a matter of principle.  I don't think
metapackages are somehow special.  The contents of important
metapackages such as the ones we're discussing here have very
wide-ranging effects.

> If you disagree with *someones* opinion, you are free to not use the 
> metapackage. And it is easy. The metapackage itself does not offer any 
> functionality.

This is not a practical approach.  Users who want to avoid n-m would
have to remove at least the gnome and gnome-core metapackages, and
presumably someone would have to make replacements for them to install
instead.

With the status quo, users who have already deliberately decided to
remove network-manager will have it reinstalled during the squeeze to
wheezy upgrade.  I don't think that's right.

> NM is also the technology that Gnome has chosen to couple tightly with the 
> shell in order to provide what upstream thinks is the best possible Gnome 
> experience. We should allow our people to be able to provide what upstream 
> thinks is the best possible experience.

No, we should provide what _we_ think is the best possible experience.
In the first instance that's the maintainer's decision.  But
maintainers sometimes get things wrong, and that's why we have the TC.

> Also note that the coupling between gnome-shell and NM has gotten
> much stronger since squeeze, so it is not unreasonable to require it
> harder than in the squeeze days. Software evolve.

Experiemnts reported on debian-devel show that this `tight coupling'
is more a matter of doctrine than an actual hard functional
dependency.

Indeed on two of our platorms network-manager isn't even supported, so
it is just left out of the gnome-core metapackage!

Ian.