Bug#681834: network-manager, gnome, Recommends vs Depends
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.
Reply to: