Hi, On Fri, Apr 15, 2011 at 10:03:40AM +0100, Jon Dowland wrote: > For the record, this was (at least) bugs #432322 and #439917, and I'm > extremely > pleased that the issues have been resolved. Well done and thank you to all > involved.
AIUI they weren't resolved, but the scope of the problem was significantly minimized, which is important to note. I.e. in testing/unstable wired ethernet connections are no longer bounced during upgrade/removal. (again AIUI) In the remaining use cases network connections *are* bounced, but in the postinst rather than preinst/postinst, which lowers the chance of Bad Things happening to your network-based upgrades. And AFAIK such connections are still torn down during package removal. > Could those thread participants who have gripes from their last NM experience > many years ago please confirm that their gripes still apply before continuing > with the discussion? (I'll assume that the slightly-less-than-polite[1] nature of this request is directed at others, but will field the question anyway) I use NM on a daily basis, and am somewhere between "generally" and "very" happy with the experience in the scope that I use it. I don't have anecdotal complaints as much as I see some potentially big problems with having NM be a _default_for_all_installs_. Plus, I haven't seen (even after asking) what the benefit is that outweighs these problems: * n-m does not support the same level of variety in network configurations, which is a regression for some subset of server environments. * any bouncing of network connections during package install/upgrade/removal is still a regression/risk even if limited in scope. * glib isn't the best library on top of which to build such a critical system level service[2] * it would result in a size/complexity growth to the standard installation. * it would require changes in long-standing practices if ifup, ifdown, and /e/n/i are no longer the preferred way to handle network configuration[3]. * requiring dbus, last I checked, would increase the likelihood of upgrades requiring manual intervention and/or reboot[4]. Allowing for "but you can always uninstall this and install ifupdown" is fine[5], except, why should the admin have to do so in the first place, as opposed to "if you really want network-manager on your server you can install it"? I'm not trying to be knee-jerk obstructionist[6] here. If we decide that we have good reasons to have a stateful network configuration daemon in every install by default, so be it, it's not my call anyway. But the implementation of *this* stateful network configuration daemon leaves a bit to be desired and I'm still waiting on what the rationale is for *why* we want to have it in the first place, hence my voicing of concerns. BR Sean [1] "Gripe" isn't really a constructive way to describe what could be valid and potentially significant issues. [2] the glib allocation behavior being one example. [3] this also would affect *packages* using ifup/etc or the /e/n/if-*.d/* hooks [4] that'd be #495257 which is a whole other can of worms, and I assume most admins would rather we keep servers out of that when possible. [5] though if you happen to be installing debian on a remote device that has a connection other than wired-ethernet, you suddenly have problems getting rid of NM without locking yourself out. [6] nor a "get off my lawn u damn kids, learn to RTFM" type either. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110415111923.ga28...@cobija.connexer.com