Bug#688772: gnome Depends network-manager-gnome
On Friday, October 05, 2012 23:26:01, Don Armstrong wrote:
> On Sat, 06 Oct 2012, Josselin Mouette wrote:
[…]
> > * The affirmation that this will cause undesirable upgrade behavior
> > is grossly exaggerated.
>
> From what I understand, nm and wicd are not capable of co-existing.[1]
As it has been mentioned that n-m had design issues that it may no longer
have, it means that /when/ I was having the issues I cited in the link above
with n-m may be important. I looked into my records, and the issues I was
having with n-m breakage on upgrades, n-m interfering with wicd, and upgrades
of n-m "undoing" user-made init script modifications to disable it occurred in
the Fall of 2009. Package/metapackage dependencies were also directly related
to why I was having the issue at the time too -- I remember trying to remove
n-m and found the system "fighting me" on it, and was too busy to work out how
to immediately get around the dependencies; I had the technical capability to
do so, but my focus needed to be elsewhere. Instead I kept having to use the
"field bandage" of re-modifying the init script after n-m broke the use of
wicd on each upgrade. IIRC I eventually ended up having to compromise and
remove certain programs I used and liked in order to remove n-m. wicd at that
time did not have a wicd-kde package, so I used wicd-gtk and wicd-curses; it
didn't matter much to me that these didn't integrate with the rest of the
system, because unlike n-m they didn't break on upgrades.
As I also mentioned [2], recent changes to the task-xfce-desktop package in
Wheezy pulled in n-m in a VM I run even though wicd had previously been
installed by default, and at least for the wired interface there didn't seem
to be a bad interaction.
I think my data on n-m is outdated, so I think more present-day testing of n-m
and wicd interaction is needed to know if any conflicts exist today.
> > * The claim that NM can be replaced by another component without
> > functionality loss is preposterous.
>
> Which functionality loss are we talking about? For simple
> configurations, it seems quite possible to replace NM with ifupdown
> with no loss of functionality.
One cited example: Phillip Kern mentioned [3] that n-m supports IPv6 where
wicd does not, which is why he had to switch back from wicd.
I'm not convinced by the argument of "functionality loss" compared to another
component as a reason for the Dependency. If an alternative works fine for
the user, I don't see why continuing to use it /shouldn't/ be allowed without
having to work-around the metapackage. I agree that n-m /does/ have
additional features to alternatives (and that it integrates better with
Gnome), but that still does /not/ mean that every user would want it or need
it. For instance there are often features n-m has that a user won't have the
capability of taking advantage of because they lack the hardware to do so.
I share Colin's concerns about having to work around the metapackage. Being
that Debian's mantra is "The /Universal/ Operating System", this implies that
it tries to cater to everyone, including those who my not yet have figured out
what reverse dependencies are and how to work around the metapackage at their
own risk. Removing one package and installing another is generally a
operation of a lower bar than working around a metapackage is. An interesting
situation to consider in this context is accidentily removing the network
configuration tool on a wireless-only system, and thus not having network
connectivity to install another one.
In addition my experience it's common to install several Window Managers and
Development Environments simultaneously on shared systems as well as users
wishing to try out the various choices; I think the dependency on n-m in the
gnome metapackage may impact that experience. It's of course also common to
run Gnome programs from a different DE or WM than Gnome, too. For both of
these reasons, the fact that the gnome metapackage is installed doesn't
necessarily mean Gnome is the primary environment being used.
I think this issue borders the gap between "user experience design" and
"allowing user choice by design". I believe the Gnome maintainers are looking
more towards the former, and I think the dependency has some impact on the
latter. I'm still not sure I understand the ramifications of a focus on the
latter; that is, what if any negative impact there would be if n-m was a
Recommends in the gnome metapackage.
> 1: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=681834#215
2: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=681834#235
3: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=681834#255
-- Chris
--
Chris Knadle
Chris.Knadle@coredump.us
Reply to: