Re: network-manager as default? No!
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
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 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
* 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
* requiring dbus, last I checked, would increase the likelihood of upgrades
requiring manual intervention and/or reboot.
Allowing for "but you can always uninstall this and install ifupdown" is
fine, 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 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.
 "Gripe" isn't really a constructive way to describe what could be
valid and potentially significant issues.
 the glib allocation behavior being one example.
 this also would affect *packages* using ifup/etc or the /e/n/if-*.d/* hooks
 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.
 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.
 nor a "get off my lawn u damn kids, learn to RTFM" type either.