Bug#688772: gnome Depends network-manager-gnome

[Ian Jackson]

Don Armstrong writes ("Bug#688772: gnome Depends network-manager-gnome"):
> B 4. We overrule the decision of the meta-gnome maintainers to add a
> B    dependency from gnome to network-manager-gnome; this dependency
> B    should be [-removed for the release of wheezy. After the release of
> B    wheezy, if-] {+removed. If+} in the opinion of the NM maintainer {+(and
> B    before the release of wheezy the Release Managers)+} the concerns
> B    raised in §4 of the CTTE decision #681834 have been addressed
> B    through technical [-means,-] {+means (e.g. by preventing the starting of NM as
> B    discussed in #688772),+} the meta-gnome maintainers may freely
> B    adjust the dependencies as usual.

Obviously we should have this on the ballot if other TC members want
it.

But I am opposed to it because:


Firstly, and most importantly:

There is no technical reason to prefer a situation where the user has
n-m installed but disabled to one where they don't have it installed.

There _are_ technical reasons why (on systems where n-m's operation
is not desired) not installing it is better.

This for me is the critical point.  Can _anyone_ provide a coherent
and fact-based explanation for why this is a good idea ?  (And I mean
why this is a _technically_ good idea.  "It might help placate the
maintainers" is not a technical reason.)

The biggest technical downside is that this approach doesn't solve the
upgrade problem without a good deal of complicated machinery to try to
determine whether the system should pretend that n-m isn't installed
(or annoying prompts, or something).


Secondly, there is a process/approval problem here for the post-wheezy
case.  I think this resolution text effectively neuters itself after
wheezy since AIUI the n-m maintainers naturally think that all the
concerns are _already_ satisfactorily addressed.  If the n-m
maintainers felt that the concerns of n-m sceptics _weren't_
satisfactorily addressed _already_ they would surely not be pushing
n-m so hard right now.

So this is likely to result in the n-m maintainers engaging in some
kind of make-work (which both they and n-m sceptics consider futile)
to try to comply with a ruling which they don't agree with but which
delegates part of the decision back to them.  And then, when the
make-work turns out not to satisfy, further escalation and bad
feeling.

If we are overruling the maintainer we should not ask them to be the
judge of whether their fix is sufficient.  We should either make the
requirements objective, or nominate someone else to make the decision.

Alternatively, if it's intended that after wheezy the maintainers will
do whatever they feel appropriate then the resolution should
explicitly limit the scope of the overruling to wheezy and have a new
advisory paragraph for the post-wheezy case.  (I mention this for
completeness; I wouldn't agree with that approach.)


Ian.