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

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

Russ Allbery writes ("Re: Bug#681834: network-manager, gnome, Recommends vs Depends"):
> As I understand it, the timeline here looks something like:
> 
> 1. network-manager was a Recommends in squeeze.
> 
> 2. GNOME maintainers get a bunch of bugs from confused users who don't
>    install Recommends for some reason and then don't get network-manager
>    and perceive a crippled system.

Are you sure this is what happened ?  We have had very few users
complaining on -devel who have globally disabled Recommends, although
they have been very loud and insistent.

If this _is_ what happened then there should be evidence in the form
of bug reports.

> 3. GNOME maintainers upgrade Recommends to Depends to solve, from their
>    perspective, those bugs.

None of the gnome maintainers have made this argument to us so far.
Instead, the arguments made that I can recall have been:

 - The gnome-core metapackage should be the same as what upstream
   think of as the GNOME core.  (I don't think this is very important.)

 - Metapackages are supposed to be the subjective opinion of the
   maintainer and therefore it is not proper to consider overruling
   the maintainer.  (I disagree.)

 - There are other ways of disabling network-manager which the
   maintainers prefer.  (These other ways are less good from a
   technical point of view and no-one has proposed a technical
   advantage for them.)

 - Not installing n-m breaks things so it's actually a hard
   dependency.  (This turns not out not to be true - at least, not
   installing n-m is no worse than disabling it, or having a network
   connection not managed by n-m, and in any case the things which
   don't work are minor and not unexpected for a user who has
   made deliberate choice against n-m.)

 - The criticisms of n-m are FUD and it's much better nowadays.
   (There seem to be ample people still complaining and we should
   respect their wishes.)

As you can see none of these are good reasons.

The closest we have to what you suggest, Russ, is this from Josselin:

  Because doing so is like ensuring there will be some systems that don’t
  work correctly, wasting our time on bug reports that can be fixed just
  by installing the missing recommends.

This was not presented as an argument to the TC; it occurs in #645656
and doesn't seem to be substantiated.  It reads to me like a
repetition of the claim that deinstalling n-m breaks everything (which
is of course not consistent with the idea that disabling it is OK).

> I think this argument has substantial validity.  It seems reasonable to
> apply, as a general principle, the idea that we should cater to people who
> are using the system as documented over people who are using it
> incorrectly, and that if there are a lot of people using it incorrectly,
> that's probably a bug in our education or documentation rather than in how
> we use the system.  But I do think that it's possible to disagree with
> this argument, and to some extent it's situational.

I would accept this as a consideration if someone would show me these
"lot of people" who are using it incorrectly and become confused as a
result.

People who are using it incorrectly because they disagree about what
"correctly" means, and have malfunctions as a result, are not
"confused".  They just need to be told not to file bugs about this.
They do not need our help.

> That's why, with changes like this, one often sees an unstable fluctuation
> between the two alternatives because, at any given time, responding to the
> squeaky wheel (the users who are actively complaining) means flipping the
> state back to the other alternative.

I don't think that's what's happened here.

I think rather that the gnome maintainers agree with upstream's desire
to push network-manager as hard as they can and are simply trying to
reflect GNOME upstream's increasingly strong doctrine that n-m is an
integral part of GNOME.  That's certainly what the gnome-core
maintainers have been telling us.

Ian.