Bug#688772: gnome Depends network-manager-gnome
Russ Allbery writes ("Bug#688772: gnome Depends network-manager-gnome"):
> I've been thinking about this over lunch, and I do feel like the gnome
> metapackage is substantively different than the gnome-core metapackage.
> I'm not sure if it's sufficiently different to warrant a different
> decision, but it does seem different enough to warrant a separate
> discussion.
Most of the points that were determinative of our decision on
gnome-core apply to gnome too.
> The historic point of the gnome metapackage is not to just install the
> base machinery of GNOME in the same way that gnome-core is. It's rather
> to give the user a complete desktop environment built around GNOME. There
> have historically been all sorts of applications in there that people may
> or may not use. It's a fairly "heavy-weight" metapackage; it pulls in
> everything from office suites to a mail client.
All of that is fine but of course as you yourself wrote:
4. For most applications and components, the only drawback of this would
be some additional disk space usage, since the application, despite
being installed, wouldn't need to be used. However, network-manager
assumes that, if it is installed, it should attempt to manage the
system's network configuration. It attempts to avoid overriding local
manual configuration, but it isn't able to detect all cases where the
user is using some other component or system to manage networking.
The user has to take separate, explicit (and somewhat unusual for the
average user) action to disable network-manager after it has been
installed.
So n-m is special.
> We still have the upgrade problem with network-manager from squeeze gnome
> to wheezy gnome, but I would expect, if I had the full gnome metapackage
> installed, for quite a lot to potentially change across versions: new
> applications added or dropped, new implementations of particular common
> tasks to be blessed upstream, etc. So I'm not sure if that's as strong of
> a reason to stick with Recommends in that metapackage.
The point is that if a user deliberately deinstalls something (as
would have to be the case with a violated Recommends in squeeze), we
should not undo that decision willy-nilly.
>From the point of view of the gnome metapackage, I can see no
justification at all for the increased strictness of the dependency.
The fact that GNOME upstream have decreed that n-m is part of "GNOME
Core" rather than just part of "GNOME" isn't relevant to the gnome
metapackage, except insofar as it means that the dependency should
move down onto gnome-core.
> To be clear, if I were the GNOME maintainers, I would use Recommends. But
> I'm not, and I'd rather that they make the call as much as possible.
The issues seem very similar to me. It is perhaps less important that
people be able to conveniently install a whole application suite
without getting n-m.
But the upgrade issue is the same and will affect nearly as many
users. And on the face of it it is simply entirely wrong to upgrade
the dependency. I can see no justification for it. And the
maintainers haven't even provided one!
> Putting aside the communication breakdowns and the heated arguments and so
> forth, if just the gnome metapackage issue in its current form had come to
> us cold, I'm trying to work through what decision I'd make.
I would have made the same decision.
But I'm not convinced that this is the right basis to think about it.
It is not a good precedent to set that if a matter is brought to the
TC, the maintainer who loses the debate in the TC will do something
which undermines the effect of the TC decision and which wasn't
proposed in the TC discussion.
Having taken hold of the matter and overruled the maintainer, we have
a responsibility to see through the consequences, and to avoid
backsliding by the maintainer.
> I'm wondering if we should just document the change to the gnome
> metapackage in the release notes. I think there's really something to be
> said for treating this as a compromise position.
What you are proposing is a compromise between doing the right thing
for our users, and upholding the autonomy of the maintainer.
That is contrary to our stated principles.
Ian.
Reply to: