Am 07.05.2015 um 19:30 schrieb Dan Williams: > On Thu, 2015-05-07 at 19:08 +0200, Michael Biebl wrote: >> Am 07.05.2015 um 18:09 schrieb Dan Williams: >>> 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.
That would be nice, thanks! I think, it should only skip any fallbacks if rc-manager=resolvconf is explicitly set *and* the resolvconf binary does exist. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
