[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#688772: gnome Depends network-manager-gnome

Hi Noel,

On Tue, Nov 13, 2012 at 07:23:51PM +0000, Noel David Torres Taño wrote:

> My main concern when raising #681834 is that NM breaks my desktop system,
> not by breaking its network, but but rendering some of its applications
> unusable.  This seems not to have been addressed yet.

> The example I put once and again is that when I use pidgin, if NM is
> installed (and since my network is configured statically in /e/n/i) pidgin
> thinks I have no working network connection (which I have) and refuses to
> connect, while with NM not installed pidgin works properly.

I believe this is out of scope of the current question; but for the record,
I would consider that an obvious and release-critical bug in NM if having NM
installed but disabled in favor of static /etc/network/interfaces causes
applications to consider themselves "offline".  The correct default behavior
when NM is not in control of the network is to assume that the system is
*on*line.  (Furthermore, I think the whole idea of needing custom desktop
infrastructure to tell apps whether they're online or not is silly; you're
online if you have a default route.  Everything else - like deciding you
don't want to use your expensive 3G connection for certain kinds of data use
- is valuable, but it's icing; and it should never cause an app to fail to
use the perfectly good network just because this additional desktop service
is unavailable.)

I'm pretty sure even without talking to him that the NM maintainer would
agree with me that the following are requirements for NM's "are we online?"

 - If NM is not installed, the app must assume you're online.
 - If NM is installed but disabled (not running), the app must assume you're
 - If NM is installed and running but knows that it's not managing one or
   more network connections (because these are configured in, e.g.,
   /etc/network/interfaces instead), NM must tell apps that they are online.
 - If NM is configured to control all interfaces it knows about on the
   system, only then is it allowed to tell apps if they are on or off line.

If any of this is controversial, I'm happy to discuss it further - but I
think this would be best done via a bug report against network-manager, not
via the technical committee.  Regardless, as failure to comply with any of
the above would be a plain - and plainly fixable - bug in NM and associated
libraries, I don't think that such a bug is a reason for me to vote against
a gnome dependency on NM.  Like many of the bugs that have been described in
this thread, any of the above are things that should be fixed for the good
of our users *regardless* of whether gnome depends on NM.

> This is the reason for which I consciously decided to deinstall NM knowing
> that it breaks a Recommends.  It was an explicit decision by me (the
> user), and having it overruled by the Debian Gnome team caused me some
> problems (yes, I do not track stable but unstable).

> I'm happy with NM being installed by default (I want it on my next laptop, 
> which will use Debian Gnome), but I also want my decision to deinstall it 
> being respected.

From my perspective, this is overspecifying the solution.  Being able to
arbitrarily uninstall a dependency of a package, regardless of which package
or why it's there, is not a requirement of Debian.  And indeed, if you
really want to countermand the maintainer regarding a package dependency,
there's always the 'equivs' tool for that.  The requirements that we
*should* have for the system, and that I think everyone can agree on, are:

 - Installing the gnome or the NM package must not cause the network to
   break on upgrade, even temporarily, under any circumstances.
 - Installing the gnome or the NM package must not cause any network
   configuration the user has specified to be lost.
 - Whenever it is possible to determine the user's preference, installing
   the gnome or the NM package must not cause settings in another
   configuration location (either /e/n/i or elsewhere) to be superseded by
   configuration in NM's own internal database, even if the configuration is
   functionally equivalent.
 - Installing the gnome or the NM package must not interfere with the
   functionality of other network configuration GUI tools in other desktop
   environments, because having gnome (or network-manager) installed is not
   an indication that the admin wants to *use* it.

The key point here is that all the things that are problematic about
network-manager taking over the network configuration when pulled in as a
dependency on gnome are *also problematic if they happen when installing
network-manager directly*.  The only difference is the number of users
affected in each case.

If the GNOME Team and NM maintainer can assure us that all of the above
requirements are met, and that any currently-undiscovered bugs with respect
to these requirements could be fixed in a reasonable time frame for the
wheezy release, then I have no reason at all to object to gnome depending on

If the GNOME Team and NM maintainer are *not* able to commit to fulfilling
these requirements when the NM package is installed, then dropping the gnome
dependency to avoid forcing network-manager onto users' systems on upgrade
is probably a suitable remedy for that.  But I am not convinced that this is
*presently* the case and that an override of the maintainers is necessary
to force this particular remedy which, in any event, would be an imperfect
solution for the user-affecting bugs.

Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

Attachment: signature.asc
Description: Digital signature

Reply to: