Thomas Hood wrote: > Sorry to bother you about this again, but it occurs to me now > that this would be even better: > > > #!/bin/sh > # Resolvconf packaging event hook script for the dnsmasq package > case "$1" in > install) invoke-rc.d dnsmasq restart ;; > esac > > > That is, instead of restarting dnsmasq on removal of resolvconf, > do nothing. > > When resolvconf is removed it leaves the contents of both > /etc/resolv.conf and /var/run/dnsmasq/resolv.conf unchanged. > > If dnsmasq isn't restarted then it will carry on happily > resolving names using the nameserver addresses provided to it > by resolvconf in the past. When dnsmasq is restarted, however, > it notices that resolvconf is gone and no longer reads > /var/run/dnsmasq/resolv.conf. /etc/resolv.conf contains only > "127.0.0.1" so name service is kaput from that point on. > > I see no reason to hasten the arrival of this unhappy fate, > do you? > > (It is precisely because of this problem that resolvconf 1.55 > puts up a debconf note on removal, advising the admin to reboot > the machine. > > A theoretically more "correct" solution to this problem is > for suppliers of nameserver information to add their info > back into /etc/resolv.conf when resolvonf is removed. But > we know that this will never happen.)
Hmmm. Do we just detonate the bomb, or leave it around to explode later? I think, given the debconf note telling the admin about the bomb, later is probably better. Change made. Cheers, Simon. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
