<div class="gmail_quote">On Tue, Dec 20, 2011 at 16:39, Mathieu Trudel-Lapierre <span dir="ltr"><<a href="mailto:mathieu-tl@ubuntu.com">mathieu-tl@ubuntu.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im">I've checked it builds, installs, upgrades, and removes/purges fine.</div>
There's some more testing we'll like to do for Ubuntu though, for some<br>
things that were identified in the DNS blueprint [1] we discussed at<br>
UDS-P; but we can do this at a later time.<br><br>
[1] <a href="https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-dns-resolving" target="_blank">https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-dns-resolving</a><br><font class="Apple-style-span" color="#888888"><br>

</font></blockquote><div><br></div><div> </div><div>I think that running a "smart" local nameserver is a good idea.</div><div><br></div><div>This nameserver, N, should integrate with resolvconf in the same way as other caching nameservers do.  (1) on startup it should register its address, 127.0.0.1, with resolvconf; on stop it should de-register this address; (2) it should include a hook script in /etc/resolvconf/update.d which sends the available nameserver information to N.</div>

<div><br></div><div>It sounds to me, though, as if the intent is for future NetworkManager and N (NM+N) to have exclusive control of network interfaces and resolv.conf.  In that case NM+N should Conflict with packages that configure interfaces independently of NM+N.  NM+M needn't conflict with interface configurers, however, if the latter support resolvconf and NM+N supply their own /sbin/resolvconf.</div>

<div>-- </div><div>Thomas</div></div>