[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



Ian Jackson <ijackson@chiark.greenend.org.uk> 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]


Reply to: