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

Re: Bug#688772: gnome Depends network-manager-gnome



Hi all

I do not know if you remember I am one of the interested parties on this, 
since I raised #681834.

I'm very happy of reading such a comprehensive and rational statament from the 
Gnome maintainers. I really appreciate it.

Please note that I am a (part time) Gnome user and want to continue being so.

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.

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.

More to-the-point comments below.

On Martes, 13 de noviembre de 2012 09:19:18 Jordi Mallach wrote:
> Hi,
> 
> The Debian GNOME team is well aware of the discussion regarding #688772,
> which unfortunately went down an unconstructive path. As such we thought
> it best to step back for a little bit to try and formulate our position
> more clearly and see if we could find a constructive way to get out of
> this mess. Luckily the last few mails on the thread by Don Armstrong and
> Michael Biebl already showed there was some light at the end of the tunnel
> :)
> 
> First of all, we want to make clear that the position Joss has been
> defending on this exhausting thread is shared by most, if not all, of the
> Debian GNOME team members. In other words, we all consider NM an important
> and integral part of the desktop system we're delivering, and its absence
> does degrade its operation in such a way we find inacceptable.

I am a Gnome user, and I find Gnome without NM beyond acceptable: it is 
perfectly usable. I'm using it to write this.
> 
> It is worth to point out that GNOME 3 as we will get in wheezy is a big
> departure from the GNOME 2 as delivered in lenny. Among other things GNOME
> now strives for a tightly integrated desktop, with NM being a core part of
> this desktop. In the opinion of the GNOME team the intended GNOME
> experience can only be delivered when all these tightly integrated parts
> are used together.

It should be up to the user to decide up to which completion point he desires 
an experience.
> 
> Network manager is  not an arbitrary requirement, even if GNOME Shell can
> currently run without it. NetworkManager allows GNOME to:
> - access all present and commonly used networking technologies (VPN,
> Wireless, 3G) via an integrated, very prominent icon in the main desktop
> bar. - networking needs have changed over the past years and has become
> much more dynamic and diverse. Connecting to the internet via wireless, 3G
> or VPN should be painless and easy. It should work out of the box and
> require a minimum of fuss.
> - only NetworkManager currently offers this kind of features, ifupdown is
> too static/cumbersome to setup, wicd is too limited in functionality. -
> GNOME upstream developers embraced NetworkManager as an external
> dependency and seamlessly integrated them into various parts of the
> desktop.

Some users desire precisaly this: static (thus, trustable) network 
configuration.
> 
> better integration / software being network-aware
> =================================================
> - on/offline detection: GNOME relies on NetworkManager's D-Bus messages to
>   establish if the system has a working network connection or not, and how
> to behave in either case.  Applications like Evolution or Empathy will
> only try to fetch mail if NM says there's an appropriate network link,
> avoiding errors like "Could not connect to IMAP server". Epiphany will
> enable offline mode automatically, etc.
> - PackageKit will avoid costly downloads when you're on 3G setting up new
>   connections is easy
> - integration into gnome-control-center
> - setting up a new wireless connection requires a single click via
> prominent integration into GNOME Shell

Precisely the point (within pidgin) that led me to remove NM.
> 
> upgrade problem
> ===============
> - NetworkManager was first introduced in lenny, the first release
> installing recommends by default.
> - network-manager-gnome was added a Recommends to the "gnome" meta-package
> in lenny.
> - misuse of Recommends was a widespread problem in lenny, so quite a few
> users disabled Recommends back then.
> - NetworkManager 0.6 in lenny was very limited, e.g. only supported DHCP.
> It is not comparable with the version we ship in wheezy.

Usage of Recommends for metapackages has been addressed in separated CTTE 
issue #681783
> 
> NetworkManager and static interface configurations
> ==================================================
> 
> Some of the concerns raised in the discussion revolve about the
> possibility of NetworkManager starting in the middle of an upgrade and
> taking over a statically configured interface in /etc/network/interfaces.
> We don't think there's much discussion about that: if that happens, it's a
> critical RC bug that needs to be fixed. The same already applies to
> regressions network drivers in the kernel, libc6 or other basic core
> components which could break a remote Debian dist-upgrade.

I fully agree. Also, I do not think this is an issue in current NM, unless NM 
configures an inactive connection and thus renders the computer either
a) reachable via a non-intended network, previously down
b) change its routing table

Please note that I do not know if NM modifies the default gateway if it finds 
and configures a previously unconfigured network card, but a) is a problem 
anyway.
> 
> multiple connection managers problem
> ====================================
> 
> One of the real issues when NM is a Depend of the meta-packages is that it
> violated the principle of "do no harm" when being installed on a system
> which already has a connection manager (such as wicd or less commonly
> connman). While this is not a problem specific to NM (installing wicd on
> an NM system causes the same problem), the problem is of course triggered
> by the Depend in the gnome meta package.
> 
> Solving this issue properly will not only make the biggest issues seen with
> gnome depending on NM go away, but will also improve Debian as a whole,
> which is of course always worthwhile.

I fully agree
> 
> The best solution we can currently propose for this issue is to add some
> maintainer script logic to present a debconf prompt (similar to how we
> currently manage multiple display managers like gdm and kdm which can be
> installed at the same time). To avoid unnecessary debconf prompts, the
> debconf prompt would only be shown if such a "conflict" situation is
> detected.

Correct. But this leaves unadressed the issue of explicit user decision to 
have NM uninstalled even knowing it is a Recommends.
> 
> Michael has done a proof of concept implementation [1] which is one step
> in that direction, by simply having NM provide a prompt when it detects
> that the wicd binary is installed. A more full implemenation would of
> course require modifications to the wicd package (and connman) as well.

Please think that there are users that want to stick with ifupdown/ifconfig 
only.
> 
> If the details of the technical implementation of this solution aren't
> considered out of scope for this bug report and the CTTE, we are happy to
> discuss a more detailed plan.
> 
> On behalf of the Debian GNOME team,
> Jordi Mallach
> Sjoerd Simons
> Michael Biebl
> 
> [1]
> http://anonscm.debian.org/gitweb/?p=pkg-utopia/network-manager.git;a=short
> log;h=refs/heads/wip/debconf

Again, I want to thank you three for this coherent text and your effort to 
settle this issue.

Regards

Noel Torres
er Envite

-------------------------
A: Because it breaks the logical flow of discussion.
Q: Why is top posting bad?

Attachment: signature.asc
Description: This is a digitally signed message part.


Reply to: