On Fri, 2005-07-29 at 22:10 +0200, Thomas Hood wrote: > Will Dyson wrote: > > Now, one could say that the real solution here is for Debian/Ubuntu > > packages of NetworkManager to Conflict: with resolvconf. But playing > > nice with resolvconf is so easy, I just don't understand the objection > > to it. > > One advantage of resolvconf is that it already supports delivery of > nameserver addresses to dnsmasq and pdnsd as well as bind9. It is > also compatible with nscd. So if NM uses resolvconf then it doesn't > need to run its own private instance of named and the admin is free > to choose a local caching nameserver to go along with NM. Well, yes...but I would like to pick one caching nameserver that works instead of supporting N different ones. Now, if you're making the argument that we should remove the bind code from NetworkManager and instead depend on resolvconf, that makes a certain amount of sense. My concern with that is that one of the original reasons I decided to do the managed bind setup is for VPN support; e.g. changing the BIND config to only use the VPN nameservers for subdomains of the VPN. Does resolvconf have an interface for that? > In Ubuntu and Debian it appears that NM will be packaged to be > compatible with resolvconf. If in Ubuntu the resolvconf package will be installed by default, I guess we can put in the resolvconf support in order to be more compatible until such time as NetworkManager can replace the networking system entirely. Is it going to be installed by default? I'm not trying to be a pain - if this patch would make life significantly easier for Ubuntu or Debian we can put it in. I'm trying to make the general point though that we should concentrate on end user functionality and making things work instead of churning the dependencies and code.
Attachment:
signature.asc
Description: This is a digitally signed message part