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

[Russ Allbery <rra@debian.org>]

Tollef Fog Heen <tfheen@err.no> writes:
> ]] Ian Jackson 

>> 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.

> A somewhat tangential question here – is this a general requirement?
> Doesn't that prevent maintainers from (worst case) ever upgrading
> Recommends to Depends?  I'm worried about what precedent this would be
> setting.

Yeah, I have the same concern.  I'm not fond of just stating this as a
simple requirement.

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.

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

4. Other users who understood the Recommends vs. Depends distinction and
   used it to remove network-manager from their systems intentionally now
   find it harder to do so and perceive the dependency as introducing a
   bug.

Ian's argument goes on to essentially state that it's more important to
cater to the people who understand how the dependency system works and are
using it to make intentional choices about a package that they don't want
to use than it is to cater to the people who don't understand how it works
and end up confusing themselves and creating installations that don't,
from their perspective, work.

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.

In other contexts in Debian, when we do something that is technically
correct but nonetheless confusing, that is frequently considered a bug and
we will sometimes address that bug by changing what we do to more closely
follow the expectations of users, even if it's less elegant or less
aesthetically appealing.  It's of course easy to make that decision when
the drawbacks of doing so are just loss of a sense of order or elegance,
as opposed to making harder something that we know people want to do.

This strikes me as a classic example of one of the harder types of bugs to
solve: one where there is a vocal community on both sides of somewhat
mutually exclusive alternatives.  One of the problems with trying to
address this sort of bug is that one always runs the risk of
underestimating the number people who are happy with whatever the current
situation is, since those people will not, at the current time, be
actively complaining.  (And this applies both ways: it is easy for the
GNOME maintainers to underestimate the number of people who were grateful
for the Recommends rather than Depends and focus on the confused people
filing bugs, and now currently it's easy to focus on the people who don't
want network-manager and want to make it easier to remove and miss the
people whose systems now work the way that they expect because of the
upgraded dependency.)

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.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>