Bdale Garbee writes ("Bug#681834: network-manager, gnome, Recommends vs
Depends"):
> Gergely Nagy <alger...@balabit.hu> writes:
> > As a user, my expectation is that if I install a *meta* package, then
> > the whole platform will be installed, and will be kept installed. That's
> > the main reason I install meta packages.
>
> I comprehend you, but to me the difficulty is in defining what "the
> whole platform" means and thus where the boundary should lie. In the
> current case, if someone says "I want Gnome", do they really expect that
> to include network-manager to the exclusion of all other options, or
> might they reasonably expect to be able to use wicd, or something else,
> as an alternative?
Quite.
It has also been suggested that gnome-session would be a better
package to install, but of course that excludes all of the gnome
applications - which is probably what the user wanted in this case.
> > How about a solution suggested earlier on debian-devel@? At least one of
> > the Gnome maintainers showed interest in something like this:
> >
> > * Introduce a gnome-minimal (or any other, more suitable name, really)
> > meta package, that depends on a subset of what gnome-core depends
> > now (and which would not include n-m). And gnome-core would depend
> > on this + additional stuff.
> >
> > With this, the major complaint (n-m) is solved, policy does not have to
> > change, nor do we need to overrule any maintainers.
Policy does not need to change in any case. There is nothing
forbidding the use of Recommends, or indeed any mixture of dependency
strengths, in metapackages.
> As a resolution to the specific issue at hand, I think I'd find this
> acceptable. However, it feels like a more disruptive change than just
> flipping the Depends in question to Recommends, so I'm not immediately
> convinced it's a *better* choice.
In particular, users who already have gnome-core installed, and have
previously overridden the installation of network-manager, will find
that the upgrade brings in network-manager.
I think preserving the choice of users who have done this is
important, and whatever is done should achieve that goal.
Ian.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
