On Thu, 2015-05-07 at 19:08 +0200, Michael Biebl wrote: > Hi Dan! > > Am 07.05.2015 um 18:09 schrieb Dan Williams: > > On Thu, 2015-05-07 at 13:15 +0900, Norbert Preining wrote: > >> On Thu, 07 May 2015, Michael Biebl wrote: > >>> The attached patch should fix the issue. Will poke upstream for a review > >>> and upload tomorrow. > >> > >> Thanks for the quick fix! > > > > Got found and fixed yesterday in nm-1-0... > > Hm, I don't do any changes in the nm-1-0 related to that. Where those > fixes not pushed?
Yeah, that was it. Pushed now. > > In git master there is no longer fallback if resolvconf fails for some > > reason; but the resolv.conf manager is now a config option. So we'd > > expect distros to ship a sub-package that drops a config snippet > > into /etc/NetworkManager/conf.d/ enabling resolvconf which also requires > > the resolvconf package itself, so that when the config option is set, > > resolvconf is always installed. We may need some tweaking of the > > default handling here, but the idea is that if the user specifically > > chose resolvconf and it fails, that should be a hard failure and NM > > shouldn't be touching resolv.conf since the user told NM not to... > > I kind of liked the if-resolvconf-found-use-it behaviour. > The new behaviour will be a bit icky if I go the subpackage route due to > how conffiles are handled. > conffiles (config files in /etc/) are not automatically removed by dpkg > if the package is removed (they are only removed on purge). > So if the user uninstalles (but doesn't purge) the sub-package, the > conf.d snippet will stay around and he'll get resolv.conf failures > because it's no longer guaranteed the resolvconf package is installed. Hmm, ok. I guess we'll have to allow fallback to writing resolvconf if the executable doesn't exist. dan -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
