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?" API: - 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 online. - 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 network-manager. 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