Bug#688772: gnome Depends network-manager-gnome
Don Armstrong writes ("Bug#688772: gnome Depends network-manager-gnome"):
> On Fri, 12 Oct 2012, Ian Jackson wrote:
> > Why do you think the gnome metapackage depending on, rather than
> > recommending, wicd, is a good idea?
>
> The primary case of NM breaking things is when it's installed with
> wicd, AFAICT. The other cases of NM breaking things are RC bugs in NM.
There are no other competitors to wicd and n-m then ?
> > For example, consider the position of someone who has deliberately
> > removed n-m in squeeze, and is using ifupdown or running ifconfig by
> > hand or whatever, and upgrades to wheezy. This still gives them n-m
> > back. That's not respecting their previous choice to remove it.
>
> Right, but if they get NM back, and nothing breaks because of it,[0]
> it's just the same as any other package being installed by a meta
> package. They've wasted some disk space, and they've got another
> program running, but everything continues to work.
And you're saying nothing will break because in the case where they
have wicd, n-m won't be installed because of the alternative. And in
the case where they don't have wicd "there are no such bugs that
aren't rc".
Are we sure that all these rc bugs are going to be fixed and not
downgraded at the last moment ? Are we sure that we will find them
all, for that matter, before the release ?
Given the very strong insistence by n-m's proponents that these bugs
aren't even real, in many cases, it seems more likely that n-m will be
released in wheezy with infelicities which will be argued by the gnome
maintainers to be not bugs, or not rc, or someone else's fault.
For example, if I want to use ifupdown then I probably don't want n-m
to bring up even interfaces which exist but which I haven't mentioned
in /etc/network/interfaces - but managing those interfaces is
precisely the point of n-m. So I'm cast back into "install n-m but
disable it", which is clearly inferior.
The result is surely going to be more friction between users who find
n-m doesn't work for them, and developers who insist on forcing n-m on
them.
It is very simple to avoid all of these kind of disagreements: allow
users to conveniently not have n-m if they don't want it. It seems to
me unarguable that a user who doesn't want n-m should be allowed to
not have it, and still gain the other benefits of the metapackages
provided.
In all cases where removing the hard dependency (from the gnome
metapackage, in this case) makes any difference at all, it is to the
benefit of the user in question. Assuming, as we should, that it is
to the benefit of a user who makes a conscious and informed decision
for that decision to be honoured even if some of us might not consider
it wise.
Our priorities are our users and free software. How does pushing n-m
onto unwilling users benefit the users or free software ?
> It's certainly not the way I would do it,[1] but it's one way to
> mitigate the problems with unconditionally installing NM while
> allowing a further insistence that NM be installed which the gnome
> maintainers appear to strongly believe is necessary.
They do indeed appear to strongly believe that but they have advanced
no cogent reasons. (You agree, don't you, that they haven't advanced
any cogent reasons?)
I have to say that the continued attempts to placate this unjustified
insistence are very perplexing to me, particularly given that the
"compromises" are:
- clearly technically inferior
- less respectful of our users' choices
The _only_ downside of my proposed decision is that it would annoy the
Debian gnome maintainers. Our job however is to make technical
judgements on technical questions. That doing the right thing would
annoy the maintainer, because the maintainer feels strongly but is
plainly wrong, is not a good reason for doing the wrong thing.
Ian.
Reply to: