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.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
