On Fri, 2005-07-29 at 12:12 -0400, Will Dyson wrote: > So the added value here is the removal of a potential failure case > (and one that I'm sure others will hit) when NetworkManager is stopped > or removed. NetworkManager is supposed to be friendly, and I feel that > includes doing everything it can to avoid causing breakage even in the > face of operator error (if you want to insist that using NM with > resolvconf is an error). > > Now, one could say that the real solution here is for Debian/Ubuntu > packages of NetworkManager to Conflict: with resolvconf. Right, adding a conflicts would work. Or just don't include resolvconf at all in their repositories and instead work on integrating NetworkManager by default, as we're going to do for Fedora. > But playing > nice with resolvconf is so easy, I just don't understand the objection > to it. If I remember from when I used Debian there's about 50 networking packages with various bits of functionality; we could include code in NetworkManager to e.g. optionally use ifupdown to monitor link state, guessnet for doing DHCP, etc. We could add patches to use all of these, but what's the point? Just don't install those packages. > The former. My laptop is the only machine that runs NM. All my > machines have resolvconf. What we want to do is get to the point where NM is installed everywhere, from servers to desktops to laptops. It should be *the* networking API. That way even on servers or desktops, applications can e.g. listen for D-BUS signals on network availability and react accordingly.
Attachment:
signature.asc
Description: This is a digitally signed message part