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

[Ian Jackson <ijackson@chiark.greenend.org.uk>]

It seems to me that our objectives must include:

1. Users who do not do anything special should get network-manager
   along with gnome (in this case, along with gnome-core).
    These users should continue to have network-manager installed,
   across upgrades.

2. Users should be able to conveniently install and upgrade gnome
   without network-manager.

3. Users who deliberately removed network-manager in squeeze (which
   they will generally have done by deliberately violating the
   Recommends from the gnome metapackage) should not have to do
   anything special to avoid it coming back in wheezy.

Other objectives which may be relevant include:

4. Users who do make a decision that they do not want to use
   network-manager should not have to read specific documentation,
   or temporarily have network-manager installed, risk being exposed
   to bugs in network-manager's configuration arrangements, and so
   on.

5. The `gnome-core' metapackage should in some sense perfectly or
   exactly correspond to upstream's notion of what `the gnome core'
   refers to.

6. Users who choose to globally disable Recommends should still get
   the desired behaviours as described above.

Of these I can dispose of 6 quickly.  I don't think anyone on the TC
thinks that this is a requirement, or even a `nice to have' which is
worth considering in this context.  If you disable Recommends entirely
you are responsible for the consequences.  This has been extensively
discussed and I think the conclusion is settled.  6 is irrelevant.

And 4 merits a bit more discussion.  It essentially implies that those
users should not end up installing the n-m package, even transiently.
This is because not installing a package is the simplest, clearest and
most effective way of ensuring that it has no effect on the system.


There have been approximately four approaches proposed:

A. Users who want gnome without network-manager should allow it to be
   installed, and then disable it (with update-rc.d) or the like.
   As I understand it this is the gnome maintainers' view.

B. Such users should forgo the use of the metapackages and install the
   relevant combinations of packages by hand.

C. Some new metapackage(s) should be created which are like the gnome
   metapackages but contain different package selections and in
   particular do not have a hard dependency on network-manager.

D. The dependency on network-manager from gnome-core in wheezy should
   be Recommends, not Depends.


Now let us see how each of these options fares against our goals:

                   A.             B.              C.           D.
                 refuseniks     refuseniks      create        demote to
                 install n-m,   do not use      other         Recommends
                 disable        metapackages    metapackages

1. n-m by           Yes          Yes              Yes           Yes
   default           

2. gnome            Yes          Inconvenient     Yes           Yes
   without
   n-m

3. preserve         No           No               No            Yes[2]
   n-m removal
   squeeze->wheezy

4. no n-m           No           Yes              Yes           Yes
   means not
   installed

5. gnome-core       Yes          Yes              Yes           Maybe
   like upstream                                                  [1]


[1] Whether gnome-core having a `Recommends' rather than a `Depends'
on n-m satisfies this objective is rather subjective.  Arguably it
does.

Indeed this reveals that this objective is in itself subjective: it is
not a technical objective about the behaviour of actual computers.
Rather it is a `marketing', `doctrinal' or `political' objective.  Any
actual technical content of this objective has been captured already
by the other objectives in our list.

Now the fact that some objective is in a sense `political' doesn't
mean that we should dismiss it.  Freedom - the ultimate goal of the
whole project - is itself a political objective.

But I would argue that the goal of conforming to gnome upstream's
declarations about the content of gnome is much less important to
Debian than the actual behaviour of the computers running Debian; and
it is also much less important than the freedom of our users to make
their computers do what they want (and that includes removing n-m even
if gnome upstream don't approve).

In particular I think that the requirement to honour in wheezy a
user's decision to remove n-m in squeeze is important; it is not
served by any of the other possibilities and certainly does not
outweigh their advantages (if any).

So on to:

[2] I haven't tested this upgrade myself or peered at the algorithms
in apt and aptitude but my understanding from Steve Langasek's message 
<[🔎] 20120717195515.GB21876@virgil.dodds.net> (Tue, 17 Jul 2012 12:55:15
-0700) is that in this situation n-m will not be reinstalled.
Certainly if the dependency is a Depends then preventing the
installation of n-m is practically impossible.

So 5. is the _only_ criterion in which `demote to Recommends' is not
better than all the other options.  I am left with this conclusion:

Either:

 (i) conforming to a rigid interpretation of upstream's definition of
     the contents of gnome is more important than preserving the
     previously made choices of our users (or at least allowing users
     to retain those choices), and more important than making those
     choices convenient and effective for new users;

or

 (ii) the dependency should be demoted.


In conclusion I think we should stop countenancing discussion of the
ways in which users might be able to stop an installed network-manager
package from reconfiguring their network interfaces, unless someone
can come up with a _technical_ reason why it might be desirable to
install n-m on a system where a user doesn't want to use it.

After all the purpose of a metapackage is to ensure that the right
packages are installed.

Thanks,
Ian.