Bug#681834: network-manager, gnome, Recommends vs Depends
Russ Allbery writes (Bug#681834: network-manager, gnome, Recommends vs Depends): Here's what I now have: I would be happy with this wording. Does anyone else have any comments ? Thanks, Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#681834: network-manager, gnome, Recommends vs Depends
Ian Jackson ijack...@chiark.greenend.org.uk writes: I have taken the liberty of making a version of it with the small changes that I thought were appropriate. I've done this in the tech-ctte.git repo so you if you pull can see the diffs. Below is the full text of my revised proposal. I've left my original proposal, and the original version of yours, in the git repo too, as it didn't seem right to just appropriate yours and make the changes off my own bat. Per the last IRC meeting, here's an attempt to compact your version of my draft down a bit and leave out as much of the stuff that isn't directly on-point as I could. I left all the other ones there so that one can see all the varients (probably overkill, since Git would let you do that anyway, but it seemed like a good idea at the time). I think the upgrade point is the overriding one. If it weren't for upgrade behavior for users who have gnome-core + wicd or gnome-core plus using ifupdown, there are various other possible alternatives, such as the special metapackage handling, that might be okay. But the upgrade behavior currently is really suboptimal for people who have chosen to replace network-manager. Here's what I now have: Whereas: 1. The gnome-core metapackage is intended to reflect the core of the GNOME desktop environment: the basic tools and subsystems that together constitute GNOME. The gnome metapackage is intended to reflect the broader desktop environment, including extra components and applications. 2. network-manager is the GNOME network control system, and is recommended for most GNOME users. Some Debian GNOME users don't like some of network-manager's behavior and prefer to instead use other tools, either basic ifupdown or other frameworks such as wicd. 3. In squeeze, the gnome metapackage lists network-manager in Recommends but not Depends. In wheezy, currently, network-manager has moved from gnome to gnome-core, and from Recommends to Depends. This represents a substantially increased insistance that users of the GNOME metapackages have network-manager installed; specifically, there is no longer any way to install any but the most minimal GNOME metapackage (gnome-session) without installing network-manager, and users who have gnome or gnome-core installed but have removed or never installed network-manager will have network-manager installed during an upgrade from squeeze. 4. For most applications and components, the only drawback of this would be some additional disk space usage, since the application, despite being installed, wouldn't need to be used. However, network-manager assumes that, if it is installed, it should attempt to manage the system's network configuration. It attempts to avoid overriding local manual configuration, but it isn't able to detect all cases where the user is using some other component or system to manage networking. The user has to take separate, explicit (and somewhat unusual for the average user) action to disable network-manager after it has been installed. 5. The Technical Committee believes that this will cause undesireable behavior for upgrades from squeeze, and (of somewhat lesser importance) will make it more difficult than necessary for GNOME users to swap network management components, something for which there appears to be noticable demand. We therefore believe that network-manager should be moved to Recommends in gnome-core. 6. Please note that this is not a general statement about GNOME components. It is very specific to network-manager because all of the following apply: (i) The package takes action automatically because it is installed, rather than being a component that can either be run or not at the user's choice. (ii) The package has historically been recommended rather than listed as a dependency, so existing Debian users are used to that behavior and will expect it to be preserved during upgrades. (ii) There is both demonstrable, intentional widespread replacement of that package by Debian GNOME users and no significant loss of unrelated GNOME desktop functionality by replacing it with a different component. If any of these points did not apply, the situation would be significantly different. Therefore: 7. The Technical Committee overrules the decision of the gnome-core metapackage maintainers. The dependency from gnome-core to network-manager-gnome should be downgraded to Recommends. 8. The Technical Committee requests that the Release Managers unblock the update to implement this decision, so that this change may be released in wheezy. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble?
Bug#681834: network-manager, gnome, Recommends vs Depends
Ian Jackson writes (Re: Bug#681834: network-manager, gnome, Recommends vs Depends): I agree with almost all of this. It's a good analysis. I have taken the liberty of making a version of it with the small changes that I thought were appropriate. I've done this in the tech-ctte.git repo so you if you pull can see the diffs. Below is the full text of my revised proposal. I've left my original proposal, and the original version of yours, in the git repo too, as it didn't seem right to just appropriate yours and make the changes off my own bat. Here is a discussion of the substantive changes: Russ Allbery writes: This change is, so far as the Technical Committee understands, driven primarily by user confusion and bug reports, but does not reflect a deeper or tighter integration of network-manager into GNOME than was the case in squeeze. As I say I don't think there is any significant evidence of this. ... I'm not happy with this statement in the absence of evidence (whether in the form of bug reports or mailing list postings or whatever) from users who are _actually confused_. I've simply removed that part of the assertion in my version of your proposal, leaving the part of about deeper or tighter integration. So I agree with most of your reasoning but I think your conclusion needs to be a little stronger. I would say: We therefore believe that network-manager should be moved to Recommends in gnome-core. Done in my version of your draft. And you haven't addressed the question of whether this should be done in wheezy. I have added a wheras and added a new therefore section containing the two concluding paragraphs from my draft, to make it clear exactly what the effect of the resolution is. So here's my proposal. I would be happy with this as a TC resolution, although it's quite wordy. Whereas: 1. The gnome-core metapackage is intended to reflect the core of the GNOME desktop environment: the basic tools and subsystems that together constitute GNOME. The gnome metapackage is intended to reflect the broader desktop environment, including extra components and applications. 2. network-manager is the GNOME network control system, and is recommended for most GNOME users. Some Debian GNOME users don't like some of network-manager's behavior and prefer to instead use other tools, either basic ifupdown or other frameworks such as wicd. 3. In squeeze, the gnome metapackage lists network-manager in Recommends but not Depends. In wheezy, currently, network-manager has moved from gnome to gnome-core, and from Recommends to Depends. This represents a substantially increased insistance that users of the GNOME metapackages have network-manager installed. This change does not reflect, so far as the Technical Committee understands, a deeper or tighter integration of network-manager into GNOME than was the case in squeeze. 4. If matters are left as they currently stand, users who have the gnome metapackages installed but do not have network-manager installed will, in the process of upgrading from squeeze to wheezy (either due to an explicit decision to remove it or an implicit decision to not install it by disabling automatic installation of Recommends), end up installing network-manager on systems where it is currently not installed. It will also no longer be possible for users to install GNOME metapackages in wheezy without installing network-manager. 5. For most applications and components, the only drawback of this would be some additional disk space usage, since the application, despite being installed, wouldn't need to be used. However, network-manager assumes that, if it is installed, it should attempt to manage the system's network configuration. It attempts to avoid overriding local manual configuration, but it isn't able to detect all cases where the user is using some other component or system to manage networking. The user has to take separate, explicit (and somewhat unusual for the average user) action to disable network-manager after it has been installed. 6. The Technical Committee believes that this will cause undesireable behavior for upgrades from squeeze, and (of somewhat lesser importance) will make it more difficult than necessary for GNOME users to swap network management components, something for which there appears to be noticable demand. We therefore believe that network-manager should be moved to Recommends in gnome-core. 7. Please note that this is not a general statement about GNOME components. It is very specific to network-manager because all of the following apply: (i) The package takes action automatically because it is installed, rather than being
Bug#681834: network-manager, gnome, Recommends vs Depends
Russ Allbery writes (Bug#681834: network-manager, gnome, Recommends vs Depends): Ian Jackson ijack...@chiark.greenend.org.uk writes: How about this: This doesn't feel quite right to me, but I'm not sure how to phrase my feeling in terms of specific objections. Let me try to instead draft the sort of statement that I feel like I want to make and see what people think of it. I agree with almost all of this. It's a good analysis. This change is, so far as the Technical Committee understands, driven primarily by user confusion and bug reports, but does not reflect a deeper or tighter integration of network-manager into GNOME than was the case in squeeze. As I say I don't think there is any significant evidence of this. There is evidence of resistence from users who deliberately globally disable recommends, but those users aren't confused. I'm not happy with this statement in the absence of evidence (whether in the form of bug reports or mailing list postings or whatever) from users who are _actually confused_. The Technical Committee believes that this will cause undesireable behavior for upgrades from squeeze, and (of somewhat lesser importance) will make it more difficult than necessary for GNOME users to swap network management components, something for which there appears to be noticable demand. We therefore believe that network-manager should be either moved to Recommends in gnome-core, or moved from the gnome-core metapackage to the gnome metapackage (which is defined as including additional, optional components). Moving the dependency to gnome doesn't help completely, because there are users who want to install gnome but not network-manager. That's why in squeeze the dependency from gnome is a Recommends. I don't care very much whether the dependency is from gnome or gnome-core. But refraining from moving it from gnome to gnome-core does not obviate the need to refrain from upgrading it to Depends. So I agree with most of your reasoning but I think your conclusion needs to be a little stronger. I would say: We therefore believe that network-manager should be moved to Recommends in gnome-core. And you haven't addressed the question of whether this should be done in wheezy. Thanks, Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#681834: network-manager, gnome, Recommends vs Depends
How about this: Whereas: 1. Our technical objectives are: (i) Users who do not do anything special should get network-manager along with gnome (in this case, along with gnome-core). These users should continue to have network-manager installed, across upgrades. (ii) Users should be able to conveniently install and upgrade gnome without network-manager. (iii) Users who deliberately removed network-manager in squeeze (which they will generally have done by deliberately violating the Recommends from the gnome metapackage) should not have to do anything special to avoid it coming back in wheezy. (iv) Users who do make a decision that they do not want to use network-manager should not have to read specific documentation, or temporarily have network-manager installed, risk being exposed to bugs in network-manager's configuration arrangements, and so on. 2. Our technical objectives do NOT include: (i) The `gnome-core' metapackage should in some sense perfectly or exactly correspond to GNOME upstream's definition of `the GNOME Core', specifically including every such component as a hard Depends. (ii) The contents of any metapackage should be the correct expression of the subjective opinion of the metapackage's maintainer. (iii) Users who choose to globally disable Recommends should still get the desired behaviours as described above in point 1. 3. The solution recommended by the gnome-core maintainers is that users who do not wish to use network-manager should have it installed but disable it. Installing network-manager in these circumstances does not fully meet any of the above objectives apart from 1(i). 5. The alternative solution rejected by the gnome-core maintainers is downgrade the dependency to Recommends. This solution meets all of the objectives from point 1, except that infelicities in teh package manager may mean that the user in 1(iii) may need to take action to prevent network-manager being reinstalled during an upgrade. Therefore: 6. The Technical Committee overrules the decision of the gnome-core metapackage maintainer. The dependency from gnome-core to network-manager-gnome should be downgraded to Recommends. 7. The Technical Committee requests that the Release Managers unblock the update to implement this decision, so that this change may be released in wheezy. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#681834: network-manager, gnome, Recommends vs Depends
On Tue, Jul 17, 2012 at 01:56:45PM +0100, Ian Jackson wrote: block 645656 by 681834 thanks The argument about the dependency from gnome-core to network-manager has now reached the TC. This has been extensive discussed, most recently on debian-devel. The most recent response from Josselin is here: http://lists.debian.org/debian-devel/2012/07/msg00210.html It seems to me that: * n-m breaks the networking of enough people that this is a significant problem which should be fixed. * There is not currently another metapackage besides gnome-core that would pull in enough of the gnome system. * There is no good reason not to use Recommends (or indeed Suggests) in a metapackage. * In particular, tests have shown that the remainder of gnome functions as expected when network-manager is not installed; the situation appears to be the similar to that which occurs if n-m is installed but the system's active network connection is not one made by n-m. * Also, that there are people who choose not to install Recommends at all is not a reason not to make this change. * The present situation in wheezy appears to be a regression from squeeze. So I would propose that we: * Clarify our view that the normal rules for deciding dependency priorities apply to meta packages too; * Require no change to policy; * Overrule the maintainer of gnome-core, requiring that the dependency on network-manager be changed to Recommends; * Advise the release managers that we would prefer this change to be made in wheezy, provided it is uploaded promptly. Ian. I propose that you consider to have the gnome-core and gnome packages moved to the metapackages section of the archive. This will cause APT to mark the packages they depend on as manually installed, with the result that they will not be removed automatically anymore. A user can then just remove network-manager, which removes gnome-core (and gnome) but does not remove any other package installed by those packages. This should solve the problem for everyone. -- Julian Andres Klode - Debian Developer, Ubuntu Member See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/. pgppAWeUbro8J.pgp Description: PGP signature
Bug#681834: network-manager, gnome, Recommends vs Depends
Julian Andres Klode writes (Re: Bug#681834: network-manager, gnome, Recommends vs Depends): I propose that you consider to have the gnome-core and gnome packages moved to the metapackages section of the archive. This will cause APT to mark the packages they depend on as manually installed, with the result that they will not be removed automatically anymore. This might help but it is not a complete solution, because it means that when the set of gnome packages changes from release to release, the user will end up with the old set from the gnome they installed originally. That's not correct. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#681834: network-manager, gnome, Recommends vs Depends
Ian Jackson ijack...@chiark.greenend.org.uk writes: How about this: This doesn't feel quite right to me, but I'm not sure how to phrase my feeling in terms of specific objections. Let me try to instead draft the sort of statement that I feel like I want to make and see what people think of it. The gnome-core metapackage is intended to reflect the core of the GNOME desktop environment: the basic tools and subsystems that together constitute GNOME. The gnome metapackage is intended to reflect the broader desktop environment, including extra components and applications. network-manager is the GNOME network control system, and is recommended for most GNOME users. Some Debian GNOME users don't like some of network-manager's behavior and prefer to instead use other tools, either basic ifupdown or other frameworks such as wicd. In squeeze, the gnome metapackage lists network-manager in Recommends but not Depends. In wheezy, currently, network-manager has moved from gnome to gnome-core, and from Recommends to Depends. This represents a substantially increased insistance that users of the GNOME metapackages have network-manager installed. This change is, so far as the Technical Committee understands, driven primarily by user confusion and bug reports, but does not reflect a deeper or tighter integration of network-manager into GNOME than was the case in squeeze. If matters are left as they currently stand, users who have the gnome metapackages installed but do not have network-manager installed will, in the process of upgrading from squeeze to wheezy (either due to an explicit decision to remove it or an implicit decision to not install it by disabling automatic installation of Recommends), end up installing network-manager on systems where it is currently not installed. It will also no longer be possible for users to install GNOME metapackages in wheezy without installing network-manager. For most applications and components, the only drawback of this would be some additional disk space usage, since the application, despite being installed, wouldn't need to be used. However, network-manager assumes that, if it is installed, it should attempt to manage the system's network configuration. It attempts to avoid overriding local manual configuration, but it isn't able to detect all cases where the user is using some other component or system to manage networking. The user has to take separate, explicit (and somewhat unusual for the average user) action to disable network-manager after it has been installed. The Technical Committee believes that this will cause undesireable behavior for upgrades from squeeze, and (of somewhat lesser importance) will make it more difficult than necessary for GNOME users to swap network management components, something for which there appears to be noticable demand. We therefore believe that network-manager should be either moved to Recommends in gnome-core, or moved from the gnome-core metapackage to the gnome metapackage (which is defined as including additional, optional components). Please note that this is not a general statement about GNOME components. It is very specific to network-manager because all of the following apply: 1. The package takes action automatically because it is installed, rather than being a component that can either be run or not at the user's choice. 2. The package has historically been recommended rather than listed as a dependency, so existing Debian users are used to that behavior. 3. There is both demonstrable, intentional widespread replacement of that package by Debian GNOME users and no significant loss of unrelated GNOME desktop functionality by replacing it with a different component. If any of these points did not apply, the situation would be significantly different. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#681834: network-manager, gnome, Recommends vs Depends
On Wed, Jul 18, 2012 at 01:48:01AM +0100, Ian Jackson wrote: Michael Biebl writes (Bug#681834: network-manager, gnome, Recommends vs Depends): We thus tried a compromise, where the network-manager postinst script automatically comments out dhcp-type connections in /e/n/i (and restores them, in case the package is removed again,fwiw). So just to be clear: consider the case where a user has deliberately violated the Recommends in squeeze from gnome to network-manager, and now upgrades to wheezy. They will get network-manager back via the hard dependency from gnome-core. Presumably they don't want to deinstall `gnome', so they don't have a choice about that. If their networking is using a dhcp entry in /etc/network/interfaces, the result of installing n-m will be that this entry will be commented out. So the networking will break. I don't see how this follows. If n-m has been newly installed and is in proper working order, and it sees that there's a trivially-configured network interface in /e/n/i that it can take over, and it does so, how does networking break? And if it breaks, shouldn't we consider that a release critical bug in NM in its own right, to be fixed for wheezy, regardless of whether NM is being pulled in by default on upgrade? -- 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 Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#681834: network-manager, gnome, Recommends vs Depends
Steve Langasek writes (Bug#681834: network-manager, gnome, Recommends vs Depends): I don't see how this follows. If n-m has been newly installed and is in proper working order, and it sees that there's a trivially-configured network interface in /e/n/i that it can take over, and it does so, how does networking break? Well, two ways: firstly, because the user has been told very vigorously by the maintainers that if they didn't want n-m, they should disable it rather than removing the package. If they follow this advice the result will be that n-m took over their network interface, and then took it down when it was disabled. Secondly, it is possible for dhcp entries to be non-trivial. They may specify interesting scripts to be run, dhcp options, bridging, etc. It's not clear to me exactly which of these scenarious result in what outcome. Simply not installing the package clearly has the right outcomes and is obviously the best technical solution to the requirement not to use n-m. There is no technical advantage in having n-m installed when the user doesn't want to use it. We are only having this conversation at is because the gnome upstream and maintainers want n-m installed on people's systems for doctrinal reasons. Doctrinal reasons are not good reason IMO. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#681834: network-manager, gnome, Recommends vs Depends
On 18.07.2012 23:40, Ian Jackson wrote: Secondly, it is possible for dhcp entries to be non-trivial. They may specify interesting scripts to be run, dhcp options, bridging, etc. It's not clear to me exactly which of these scenarious result in what outcome. NM doesn't take over any such entries which have more complex options. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#681834: network-manager, gnome, Recommends vs Depends
Hi ctte I just wanted to bring here an argument that came in debian-devel: the one that says that n-m does not play well with usb0 type network interfaces [1]. I have not tested this myself, since I do not use a laptop and do not need an USB network gadget on my desktop, so I can not confirm it. But if it is true, it means that gnome chained hard dependency on network-manager is not even suitable for laptops when they need to resort to USB network cards. Another issue that has come across the discussion is about network-manager being deinstalled means n-m enabled applications break. As far as I know, n-m aware applications all have a fallback mode. My (personal) use case against network-manager is that I use pidgin, which is n-m aware, and I use a networking configuration with static interfaces (I use a static IP at home). If n-m is installed and running, pidgin does not work since it thinks there is no usable network. Deinstalling n-m (dpkg -P in my case) fixs it without needing to restart it, you just need to disable and reenable accounts. update- rc.d will do the same, but I see no point of having an unused software installed, but it comes it again on any aptitude run (together with the option of pulling gnome and al its related packages out). Also in my personal use case, n-m messing with /e/n/i is not an issue since I do not have interfaces that can get hijacked by n-m, but as it has been shown in this list, some people can have that concern. Regards Noel Torres er Envite [1] https://lists.debian.org/debian-devel/2012/07/msg00471.html signature.asc Description: This is a digitally signed message part.
Bug#681834: network-manager, gnome, Recommends vs Depends
block 645656 by 681834 thanks The argument about the dependency from gnome-core to network-manager has now reached the TC. This has been extensive discussed, most recently on debian-devel. The most recent response from Josselin is here: http://lists.debian.org/debian-devel/2012/07/msg00210.html It seems to me that: * n-m breaks the networking of enough people that this is a significant problem which should be fixed. * There is not currently another metapackage besides gnome-core that would pull in enough of the gnome system. * There is no good reason not to use Recommends (or indeed Suggests) in a metapackage. * In particular, tests have shown that the remainder of gnome functions as expected when network-manager is not installed; the situation appears to be the similar to that which occurs if n-m is installed but the system's active network connection is not one made by n-m. * Also, that there are people who choose not to install Recommends at all is not a reason not to make this change. * The present situation in wheezy appears to be a regression from squeeze. So I would propose that we: * Clarify our view that the normal rules for deciding dependency priorities apply to meta packages too; * Require no change to policy; * Overrule the maintainer of gnome-core, requiring that the dependency on network-manager be changed to Recommends; * Advise the release managers that we would prefer this change to be made in wheezy, provided it is uploaded promptly. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#681834: network-manager, gnome, Recommends vs Depends
Ian Jackson ijack...@chiark.greenend.org.uk writes: * There is no good reason not to use Recommends (or indeed Suggests) in a metapackage. I'd like to respectfully disagree here - though I've tried to express this on debian-devel@ too, apparently, with little success. As a user, my expectation is that if I install a *meta* package, then the whole platform will be installed, and will be kept installed. That's the main reason I install meta packages. With recommends, it's not particularly hard to end up in a situation where parts of the platform get forced off, and they're not going to come back unless explicitly asked. What's this gstreamer thing? Never heard of it, lets remove it. Oh, look, there goes totem. WTF was that thing again? Probably not important, otherwise it wouldn't get removed, would it? - exaggeration of course, but this is not very different from the situation where removing n-m wants to remove gnome and all the rest too. Except that currently, it's easier to notice that something bad is about to happen, and ask first. With recomends, bad things can happen with far less scarier warnings. I believe that's a very bad situation, and while possibly avoidable in stable, and even in oldstable-newstable dist-upgrade paths (at least the case where a part of the recommended set would be forced off for one reason or the other) unstable users (and testing users, until testing migration will consider recommends) will likely experience hiccups during a transition for example. Granted, testing/unstable users should be prepared to deal with issues, but if we can avoid pissing them off, we should. * The present situation in wheezy appears to be a regression from squeeze. Depends on who you ask. Many will consider gnome3 to be a regression too. So I would propose that we: * Clarify our view that the normal rules for deciding dependency priorities apply to meta packages too; * Require no change to policy; * Overrule the maintainer of gnome-core, requiring that the dependency on network-manager be changed to Recommends; * Advise the release managers that we would prefer this change to be made in wheezy, provided it is uploaded promptly. How about a solution suggested earlier on debian-devel@? At least one of the Gnome maintainers showed interest in something like this: * Introduce a gnome-minimal (or any other, more suitable name, really) meta package, that depends on a subset of what gnome-core depends now (and which would not include n-m). And gnome-core would depend on this + additional stuff. With this, the major complaint (n-m) is solved, policy does not have to change, nor do we need to overrule any maintainers. To me, this sounds like a much better idea, with less impact overall, yet, still addressing the biggest issue. Obviously, I'm biased and all that, but this was needed to be told. To avoid turning this bug report into the same thing that became of the thread on -devel, this is my first and last message here. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#681834: network-manager, gnome, Recommends vs Depends
Ian Jackson ijack...@chiark.greenend.org.uk writes: The argument about the dependency from gnome-core to network-manager has now reached the TC. FWIW, I use network-manager with xfce4 on my notebook, and with suitable configuration find it an acceptable solution for my needs. As a matter of policy, though, it seems completely unreasonable to me for a desktop environment to impose a hard decision on something like network attachment and configuration where there are multiple workable alternatives in Debian that users might reasonably expect to be able to exercise personal preference on. So I would propose that we: * Clarify our view that the normal rules for deciding dependency priorities apply to meta packages too; Agreed. * Require no change to policy; Agreed. * Overrule the maintainer of gnome-core, requiring that the dependency on network-manager be changed to Recommends; That would work. I believe our goal should be to require that there not be a hard Depends relationship. I would be equally satisfied if the dependency were just dropped, or if it were possible to craft a suitable or list of alternatives that network-manager could be the first choice of the maintainer among. I have not followed the discussion closely enough or independently studied this situation in sufficient detail to know if this is possible, however. * Advise the release managers that we would prefer this change to be made in wheezy, provided it is uploaded promptly. Agreed. Bdale pgplnLd67gFh8.pgp Description: PGP signature
Bug#681834: network-manager, gnome, Recommends vs Depends
Gergely Nagy alger...@balabit.hu writes: Ian Jackson ijack...@chiark.greenend.org.uk writes: * There is no good reason not to use Recommends (or indeed Suggests) in a metapackage. I'd like to respectfully disagree here - though I've tried to express this on debian-devel@ too, apparently, with little success. As a user, my expectation is that if I install a *meta* package, then the whole platform will be installed, and will be kept installed. That's the main reason I install meta packages. I comprehend you, but to me the difficulty is in defining what the whole platform means and thus where the boundary should lie. In the current case, if someone says I want Gnome, do they really expect that to include network-manager to the exclusion of all other options, or might they reasonably expect to be able to use wicd, or something else, as an alternative? How about a solution suggested earlier on debian-devel@? At least one of the Gnome maintainers showed interest in something like this: * Introduce a gnome-minimal (or any other, more suitable name, really) meta package, that depends on a subset of what gnome-core depends now (and which would not include n-m). And gnome-core would depend on this + additional stuff. With this, the major complaint (n-m) is solved, policy does not have to change, nor do we need to overrule any maintainers. As a resolution to the specific issue at hand, I think I'd find this acceptable. However, it feels like a more disruptive change than just flipping the Depends in question to Recommends, so I'm not immediately convinced it's a *better* choice. Bdale pgpkOXz8OyiD8.pgp Description: PGP signature
Bug#681834: network-manager, gnome, Recommends vs Depends
Bdale Garbee writes (Re: Bug#681834: network-manager, gnome, Recommends vs Depends): Ian Jackson ijack...@chiark.greenend.org.uk writes: * Overrule the maintainer of gnome-core, requiring that the dependency on network-manager be changed to Recommends; That would work. I believe our goal should be to require that there not be a hard Depends relationship. I would be equally satisfied if the dependency were just dropped, or if it were possible to craft a suitable or list of alternatives that network-manager could be the first choice of the maintainer among. I have not followed the discussion closely enough or independently studied this situation in sufficient detail to know if this is possible, however. That's a fine way to put the requirement. But given that we can't mandate that the maintainer makes the upload we should give explicit blessing to weakening the dependency rather than doing something else, so that someone who NMUs knows what they're doing. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#681834: network-manager, gnome, Recommends vs Depends
Bdale Garbee writes (Bug#681834: network-manager, gnome, Recommends vs Depends): Gergely Nagy alger...@balabit.hu writes: As a user, my expectation is that if I install a *meta* package, then the whole platform will be installed, and will be kept installed. That's the main reason I install meta packages. I comprehend you, but to me the difficulty is in defining what the whole platform means and thus where the boundary should lie. In the current case, if someone says I want Gnome, do they really expect that to include network-manager to the exclusion of all other options, or might they reasonably expect to be able to use wicd, or something else, as an alternative? Quite. It has also been suggested that gnome-session would be a better package to install, but of course that excludes all of the gnome applications - which is probably what the user wanted in this case. How about a solution suggested earlier on debian-devel@? At least one of the Gnome maintainers showed interest in something like this: * Introduce a gnome-minimal (or any other, more suitable name, really) meta package, that depends on a subset of what gnome-core depends now (and which would not include n-m). And gnome-core would depend on this + additional stuff. With this, the major complaint (n-m) is solved, policy does not have to change, nor do we need to overrule any maintainers. Policy does not need to change in any case. There is nothing forbidding the use of Recommends, or indeed any mixture of dependency strengths, in metapackages. As a resolution to the specific issue at hand, I think I'd find this acceptable. However, it feels like a more disruptive change than just flipping the Depends in question to Recommends, so I'm not immediately convinced it's a *better* choice. In particular, users who already have gnome-core installed, and have previously overridden the installation of network-manager, will find that the upgrade brings in network-manager. I think preserving the choice of users who have done this is important, and whatever is done should achieve that goal. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#681834: network-manager, gnome, Recommends vs Depends
Bdale Garbee writes (Bug#681834: network-manager, gnome, Recommends vs Depends): I believe our goal should be to require that there not be a hard Depends relationship. I would be equally satisfied if the dependency were just dropped, or if it were possible to craft a suitable or list of alternatives that network-manager could be the first choice of the maintainer among. I have not followed the discussion closely enough or independently studied this situation in sufficient detail to know if this is possible, however. Thinking about this some more, I think it would be better to mandate a specific solution. There have been many suggestions of alternative approaches which are (i) more complicated and (ii) whose effects we are not entirely sure and (iii) which would require specifying in detail, but which somehow avoid sidestep the key disputes. The key disputes seem to be: - Some people claim that metapackages should not use Recommends. I disagree. - GNOME upstream have declared Network Manager to be an integral part of GNOME and the Debian maintainer is insisting on following their lead in gnome-core. The maintainer is essentially asserting that the very purpose of the gnome-core metapackage is to reflect precisely what upstream have decreed, and that we should not deviate. I disagree; I think (a) we should feel free to deviate from upstream if doing so is better for our users and (b) anyway setting one of the dependencies to Recommends is not a significant deviation. My best argument in favour of specifying the specific solution is that we know exactly what the effects will be. If we want instead to write a resolution specify the effects, we will have to consider carefully exactly which effects we want to mandate. For example, creating another metapackage might have transitional implications; both for users upgrading from squeeze and for other packages which depend on gnome-core. Also if we want this to be in wheezy we want not to be messing about with complicated solutions. There is a risk, for example, that the maintainer might choose an approach unsuitable for release in wheezy. We can hardly tell the maintainer `you must do this but you must do it in the way you think is best for wheezy' - that would amount to asking them to undermine their own judgement. For the same reason I would like a decision quickly. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#681834: network-manager, gnome, Recommends vs Depends
Ian Jackson ijack...@chiark.greenend.org.uk writes: Bdale Garbee writes: Gergely Nagy alger...@balabit.hu writes: As a user, my expectation is that if I install a *meta* package, then the whole platform will be installed, and will be kept installed. That's the main reason I install meta packages. I comprehend you, but to me the difficulty is in defining what the whole platform means and thus where the boundary should lie. In the current case, if someone says I want Gnome, do they really expect that to include network-manager to the exclusion of all other options, or might they reasonably expect to be able to use wicd, or something else, as an alternative? Quite. It has also been suggested that gnome-session would be a better package to install, but of course that excludes all of the gnome applications - which is probably what the user wanted in this case. Do we know for certain that installation of network-manager excludes alternatives? Tollef replied to me on debian-devel wondering why people who don't want to use network-manager just disable it, which implies that there's some means to turn it off while it's still installed. (I don't think I ever investigated that.) I'm not sure how significant that is to the decision, but it sounded like people are assuming that having network-manager installed excludes use of wicd or something else, so I want to be sure people aren't making decisions based on false premises. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#681834: network-manager, gnome, Recommends vs Depends
Russ Allbery writes (Bug#681834: network-manager, gnome, Recommends vs Depends): Do we know for certain that installation of network-manager excludes alternatives? Tollef replied to me on debian-devel wondering why people who don't want to use network-manager just disable it, which implies that there's some means to turn it off while it's still installed. (I don't think I ever investigated that.) I don't know that we have investigated that. But I do know that having it install n-m might be a problem even if you can disable n-m afterwards. For example, n-m might break your network on installation. I'm not sure how significant that is to the decision, but it sounded like people are assuming that having network-manager installed excludes use of wicd or something else, so I want to be sure people aren't making decisions based on false premises. Also ISTR reading some assertions in the discussion that people who had previously installed n-m, found it troublesome and disabled it, had it reenabled somehow. Not installing something is generally a more reliable approach than asking people to fiddle with its config. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#681834: network-manager, gnome, Recommends vs Depends
Am 17.07.2012 14:56, schrieb Ian Jackson: block 645656 by 681834 thanks The argument about the dependency from gnome-core to network-manager has now reached the TC. This has been extensive discussed, most recently on debian-devel. The most recent response from Josselin is here: http://lists.debian.org/debian-devel/2012/07/msg00210.html It seems to me that: * n-m breaks the networking of enough people that this is a significant problem which should be fixed. This is pure FUD without further details. Do you have any bug numbers in particular? I don't claim that there aren't any bugs in NM but if there are issues, they should be fixed in NM. * There is not currently another metapackage besides gnome-core that would pull in enough of the gnome system. You can use gnome-session and install the additional packages you want. Also, as an alternative if you can't use network-manager for whatever reasons, you can install gnome-core and disable network-manager. This is as simple as update-rc.d network-manager disable * There is no good reason not to use Recommends (or indeed Suggests) in a metapackage. Not true, Joss put it very well at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=645656#65 Ian, you can of course dismiss all those reasons (as you did in the past), but that doesn't mean that those reasons are not valid. I have the impression that you are biased against NM regarding this issue and in general. * In particular, tests have shown that the remainder of gnome functions as expected when network-manager is not installed; the situation appears to be the similar to that which occurs if n-m is installed but the system's active network connection is not one made by n-m. Those so called tests have been done by Adam Borowski, who is known to hate NM, so he is not impartial on this topic. And no, it doesn't work as expected. GNOME users expect to be able to setup their network with a single click. None of the alternatives has a comparable integration into GNOME as network-manager. Not wicd, and definitely not ifupdown. We want to provide a coherent environment where the differenct compontents are integrated as best as possible. As for the situation where nm is installed but doesn't manage the network connection: This is actually extremely confusing to users as various bug reports have shown. So I would propose that we: * Overrule the maintainer of gnome-core, requiring that the dependency on network-manager be changed to Recommends; If you force us to do that against our better judgement, I'm handing in my resignment tomorrow. Michael signature.asc Description: OpenPGP digital signature
Bug#681834: network-manager, gnome, Recommends vs Depends
Michael Biebl bi...@debian.org writes: Also, as an alternative if you can't use network-manager for whatever reasons, you can install gnome-core and disable network-manager. This is as simple as update-rc.d network-manager disable [...] As for the situation where nm is installed but doesn't manage the network connection: This is actually extremely confusing to users as various bug reports have shown. Are these two points consistent? In other words, *is* it as simple as running: update-rc.d network-manager disable and installing wicd or something else, or is that configuration extremely confusing to users? Or did you mean something different by the last paragraph? If there's a clean way to disable network-manager, I think that's a reasonable alternative to either creating yet another meta-package or arguing about Depends vs. Recommends in gnome-core. But there seems to be a lot of debate over this point. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#681834: network-manager, gnome, Recommends vs Depends
On Tuesday 17 July 2012 19:15:34 Ian Jackson wrote: - Some people claim that metapackages should not use Recommends. I disagree. Metapackages is *someones* *subjective* opinion what a specific set should do. And this subjective opinion is up to the maintainer to figure it out. Not anyone else. If you disagree with *someones* opinion, you are free to not use the metapackage. And it is easy. The metapackage itself does not offer any functionality. - GNOME upstream have declared Network Manager to be an integral part of GNOME and the Debian maintainer is insisting on following their lead in gnome-core. The maintainer is essentially asserting that the very purpose of the gnome-core metapackage is to reflect precisely what upstream have decreed, and that we should not deviate. And this is a perfectly fine rationale. Having a set of packages that gives the user exactly what upstream is providing. Wether or not we shoul *also* offer something else is purely up to people doing the offerings. But being able to give the experience that upstream offers is important. And given what I have seen in some gnome apps, NM is needed for that experience. NM is also the technology that Gnome has chosen to couple tightly with the shell in order to provide what upstream thinks is the best possible Gnome experience. We should allow our people to be able to provide what upstream thinks is the best possible experience. implications; both for users upgrading from squeeze and for other packages which depend on gnome-core. Also note that the coupling between gnome-shell and NM has gotten much stronger since squeeze, so it is not unreasonable to require it harder than in the squeeze days. Software evolve. /Sune - who isn't a user of the above packages, but want to have the right to define what the content of the meta packages he provides should do. -- Man, how to unmount the microprocessor of a pointer of a program over the level-8 TCP icon from Word 3.6.9? First of all you neither must explore the case, nor should mount a space bar for exploring the GPU. signature.asc Description: This is a digitally signed message part.
Bug#681834: network-manager, gnome, Recommends vs Depends
On 17.07.2012 22:30, Russ Allbery wrote: Michael Biebl bi...@debian.org writes: Also, as an alternative if you can't use network-manager for whatever reasons, you can install gnome-core and disable network-manager. This is as simple as update-rc.d network-manager disable [...] As for the situation where nm is installed but doesn't manage the network connection: This is actually extremely confusing to users as various bug reports have shown. Are these two points consistent? In other words, *is* it as simple as running: update-rc.d network-manager disable and installing wicd or something else, or is that configuration extremely confusing to users? I think those points are consistent. Users which deliberatly chose to install wicd (or use other mechanisms) will most likely know what they are doing and that this will have effects on how their desktop environment will behave, e.g. that they will no longer be able to configure their network via gnome-control-center, the network indicator in the top panel will be gone, on/offline detection no longer being available, etc. As for the point of non-managed devices being confusing to users, I probably need to say a few words: In the network-manager package we go to great lengths to be a good citizen and respect existing configuration. That means, if the network-manager daemon finds a configuration in /etc/network/interfaces for a given physical device, it does not manage that device under the assumption that the user/administrator deliberately set up /e/n/i to have ifupdown manage this interface. It is hard to distinguish, which entries were created manually and which by the debian installer, though. The d-i installer typically creates a /e/n/i configuration, so users weren't able to manage this device with network-manager after a successfull installation, unless they manually removed the configuration from /e/n/i. This was extremely confusing for less experienced users and I got numerous bug reports over the years [1]. We thus tried a compromise, where the network-manager postinst script automatically comments out dhcp-type connections in /e/n/i (and restores them, in case the package is removed again,fwiw). This is admittedly quite ugly, but ifupdown didn't provide a nicer interface to achieve that at the time. Andrew has signaled interest in providing a better interface for that in ifupdown, so hopefully we can solve that in a nicer way. IIRC, the Ubuntu graphical installer no longer creates any /e/n/i configuration at all, to avoid this problem completely. If there's a clean way to disable network-manager, I think that's a reasonable alternative to either creating yet another meta-package or arguing about Depends vs. Recommends in gnome-core. But there seems to be a lot of debate over this point. Disabling network-manager via update-rc.d network-manager disable is a reliable and clean way to stop network-manager from running. It won't be magically re-enabled on upgrades or restarted, since invoke-rc.d respects if a sysv service is disabled this way. Michael P.S: I apologize for the threats to leave in my last email. I know this is not professional. This whole issue is extremely frustrating though and I'm currently quite pissed so I reacted more emotionally, then I should have. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=606268 -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#681834: network-manager, gnome, Recommends vs Depends
Michael Biebl bi...@debian.org writes: On 17.07.2012 22:30, Russ Allbery wrote: If there's a clean way to disable network-manager, I think that's a reasonable alternative to either creating yet another meta-package or arguing about Depends vs. Recommends in gnome-core. But there seems to be a lot of debate over this point. Disabling network-manager via update-rc.d network-manager disable is a reliable and clean way to stop network-manager from running. It won't be magically re-enabled on upgrades or restarted, since invoke-rc.d respects if a sysv service is disabled this way. Do you think this would be reasonable to document somewhere, since it keeps coming up? I'm not sure what the best place would be, although /usr/share/doc/gnome-core/README.Debian is at least not horrible, or possibly in the network-manager directory (or both). (Apologies if you've already done this. I didn't go look.) -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#681834: network-manager, gnome, Recommends vs Depends
Michael Biebl writes (Bug#681834: network-manager, gnome, Recommends vs Depends): We thus tried a compromise, where the network-manager postinst script automatically comments out dhcp-type connections in /e/n/i (and restores them, in case the package is removed again,fwiw). So just to be clear: consider the case where a user has deliberately violated the Recommends in squeeze from gnome to network-manager, and now upgrades to wheezy. They will get network-manager back via the hard dependency from gnome-core. Presumably they don't want to deinstall `gnome', so they don't have a choice about that. If their networking is using a dhcp entry in /etc/network/interfaces, the result of installing n-m will be that this entry will be commented out. So the networking will break. Furthermore, your proposed workaround ... Disabling network-manager via update-rc.d network-manager disable is a reliable and clean way to stop network-manager from running. It won't be magically re-enabled on upgrades or restarted, since invoke-rc.d respects if a sysv service is disabled this way. ... will not put it back. That just goes to show why installing an undesired package and disabling it is not a particularly good way to avoid any breakage it causes. And that's before we even consider bugs in the maintainer scripts. If the user's networking is using wicd then installing n-m will probably cause both wicd and n-m to manage the same interface ? That won't work well - it will probably break the networking - but at least disabling the n-m as above and restarting everything (perhaps rebooting) ought to fix it. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#681834: network-manager, gnome, Recommends vs Depends
Sune Vuorela writes (Bug#681834: network-manager, gnome, Recommends vs Depends): Metapackages is *someones* *subjective* opinion what a specific set should do. And this subjective opinion is up to the maintainer to figure it out. Not anyone else. I don't agree with this as a matter of principle. I don't think metapackages are somehow special. The contents of important metapackages such as the ones we're discussing here have very wide-ranging effects. If you disagree with *someones* opinion, you are free to not use the metapackage. And it is easy. The metapackage itself does not offer any functionality. This is not a practical approach. Users who want to avoid n-m would have to remove at least the gnome and gnome-core metapackages, and presumably someone would have to make replacements for them to install instead. With the status quo, users who have already deliberately decided to remove network-manager will have it reinstalled during the squeeze to wheezy upgrade. I don't think that's right. NM is also the technology that Gnome has chosen to couple tightly with the shell in order to provide what upstream thinks is the best possible Gnome experience. We should allow our people to be able to provide what upstream thinks is the best possible experience. No, we should provide what _we_ think is the best possible experience. In the first instance that's the maintainer's decision. But maintainers sometimes get things wrong, and that's why we have the TC. Also note that the coupling between gnome-shell and NM has gotten much stronger since squeeze, so it is not unreasonable to require it harder than in the squeeze days. Software evolve. Experiemnts reported on debian-devel show that this `tight coupling' is more a matter of doctrine than an actual hard functional dependency. Indeed on two of our platorms network-manager isn't even supported, so it is just left out of the gnome-core metapackage! Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#681834: network-manager, gnome, Recommends vs Depends
Michael Biebl writes (Re: network-manager, gnome, Recommends vs Depends): Am 17.07.2012 14:56, schrieb Ian Jackson: It seems to me that: * n-m breaks the networking of enough people that this is a significant problem which should be fixed. This is pure FUD without further details. Do you have any bug numbers in particular? I don't claim that there aren't any bugs in NM but if there are issues, they should be fixed in NM. The discussion of this has been extensive. Also, as Adam Borowski points out, it is perfectly possible for n-m to fail in a certain peculiar situation but for that not to be a bug in n-m. n-m does not have to be all things to all people, networking wise. It doesn't even necessarily have to be all things to all gnome users. The bug is in the gnome metapackages which unconditionally pull it into all systems. * There is no good reason not to use Recommends (or indeed Suggests) in a metapackage. Not true, Joss put it very well at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=645656#65 Ian, you can of course dismiss all those reasons (as you did in the past), but that doesn't mean that those reasons are not valid. I don't find those reasons convincing. I have the impression that you are biased against NM regarding this issue and in general. I'm using n-m myself on the very computer I'm now typing at, after having switched to it from ifupdown in my previous install, and have no regrets on that score. Please refrain from personal attacks. * In particular, tests have shown that the remainder of gnome functions as expected when network-manager is not installed; the situation appears to be the similar to that which occurs if n-m is installed but the system's active network connection is not one made by n-m. Those so called tests have been done by Adam Borowski, who is known to hate NM, so he is not impartial on this topic. However, he has actually done the tests. We should believe him unless you can show that he has made a mistake. Furthermore, you are coming rather close to accusing him of dishonesty. If you would like to do tests of your own, I'd be interested to hear about any serious malfunctions which would be unreasonable in context (the context being a user who has deliberately violated a Recommends and deliberately deinstalled gnome's networking management components). And no, it doesn't work as expected. GNOME users expect to be able to setup their network with a single click. You are twisting my word `expected'. What I meant was that a user who deinstalls network-manager, deliberately violating the Recommends, should reasonably expect that some network-related things in gnome won't work quite right (or at all). That, presumably, is the price they are willing to pay. They express that choice precisely by violating the Recommends. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#681834: network-manager, gnome, Recommends vs Depends
Russ Allbery writes (Bug#681834: network-manager, gnome, Recommends vs Depends): Michael Biebl bi...@debian.org writes: Also, as an alternative if you can't use network-manager for whatever reasons, you can install gnome-core and disable network-manager. This is as simple as update-rc.d network-manager disable [...] As for the situation where nm is installed but doesn't manage the network connection: This is actually extremely confusing to users as various bug reports have shown. Are these two points consistent? In other words, *is* it as simple as running: update-rc.d network-manager disable and installing wicd or something else, or is that configuration extremely confusing to users? Or did you mean something different by the last paragraph? No, I think you have read Michael correctly. The extremely confusing situation you get if you disable it as suggested above is the same extremely confusing situation you get if you deinstall it. Apart from any damage done to your alternative networking arrangements by the maintainer scripts, possible transient interruption to your networking while you attempt to fix the configuration (hopefully not remotely), etc. (And it's not clear to me how the gnome programs react to n-m being started and then stopped. Transiently having n-m running because the package gets installed and then disabled might mean that some of them need to be restarted AFAICT from the reports on -devel.) Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
