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

July 17th, 2012 - 09:20 am ET by Ian Jackson | Report spam
block 645656 by 681834
thanks

The argument about the dependency from gnome-core to network-manager
has now reached the TC. This has been extensive discussed, most
recently on debian-devel. The most recent response from Josselin is
here:
http://lists.debian.org/debian-deve...00210.html

It seems to me that:

* n-m breaks the networking of enough people that this is a
significant problem which should be fixed.

* There is not currently another metapackage besides gnome-core that
would pull in enough of the gnome system.

* There is no good reason not to use Recommends (or indeed Suggests)
in a metapackage.

* In particular, tests have shown that the remainder of gnome
functions as expected when network-manager is not installed; the
situation appears to be the similar to that which occurs if n-m is
installed but the system's active network connection is not one
made by n-m.

* Also, that there are people who choose not to install Recommends at
all is not a reason not to make this change.

* The present situation in wheezy appears to be a regression from
squeeze.

So I would propose that we:

* Clarify our view that the normal rules for deciding dependency
priorities apply to meta packages too;

* Require no change to policy;

* Overrule the maintainer of gnome-core, requiring that the
dependency on network-manager be changed to Recommends;

* Advise the release managers that we would prefer this change to be
made in wheezy, provided it is uploaded promptly.

Ian.


To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
email Follow the discussionReplies 26 repliesReplies Make a reply

Replies

#1 Gergely Nagy
July 17th, 2012 - 10:30 am ET | Report spam
Ian Jackson writes:

* There is no good reason not to use Recommends (or indeed Suggests)
in a metapackage.



I'd like to respectfully disagree here - though I've tried to express
this on debian-devel@ too, apparently, with little success.

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.

With recommends, it's not particularly hard to end up in a situation
where parts of the platform get forced off, and they're not going to
come back unless explicitly asked. "What's this gstreamer thing? Never
heard of it, lets remove it. Oh, look, there goes totem. WTF was that
thing again? Probably not important, otherwise it wouldn't get removed,
would it?" - exaggeration of course, but this is not very different from
the situation where removing n-m wants to remove gnome and all the rest
too. Except that currently, it's easier to notice that something bad is
about to happen, and ask first. With recomends, bad things can happen
with far less scarier warnings.

I believe that's a very bad situation, and while possibly avoidable in
stable, and even in oldstable->newstable dist-upgrade paths (at least
the case where a part of the recommended set would be forced off for one
reason or the other) unstable users (and testing users, until testing
migration will consider recommends) will likely experience hiccups
during a transition for example.

Granted, testing/unstable users should be prepared to deal with issues,
but if we can avoid pissing them off, we should.

* The present situation in wheezy appears to be a regression from
squeeze.



Depends on who you ask. Many will consider gnome3 to be a regression
too.

So I would propose that we:

* Clarify our view that the normal rules for deciding dependency
priorities apply to meta packages too;

* Require no change to policy;

* Overrule the maintainer of gnome-core, requiring that the
dependency on network-manager be changed to Recommends;

* Advise the release managers that we would prefer this change to be
made in wheezy, provided it is uploaded promptly.



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.

To me, this sounds like a much better idea, with less impact overall,
yet, still addressing the biggest issue.

Obviously, I'm biased and all that, but this was needed to be told. To
avoid turning this bug report into the same thing that became of the
thread on -devel, this is my first and last message here.

|8]


To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact

Similar topics