[Resolvconf-devel] Bug#567059: Suggestions for implementation

[Thomas Hood]

Regarding the discussion snippet posted in #563386 [1]:

> Addendum: snippet from #debian-devel where I discussed above:
>
> <peej> package A installs stuff which requires package B to restart. Is
> that a job for postinst scripts?
> <Yoe> peej: I'd say that's a job for a trigger by package B
> <peej> I am unfamiliar with debian packaging. Can you explain what you
> mean by trigger?
> <jcristau> peej: /usr/share/doc/dpkg/triggers.txt.gz
> <peej> cool.
> <cortana> or not even triggers. if package b has a daemon that needs to
> reload, it should just watch the directory containing the files and reload
> when new ones appear
> <Yoe> cortana: yes, but then not all daemons do that
> <cortana> yeah. if the maintainer patches the daemon then other distros
> can benefit too :)
> <Yoe> and a trigger may be easier to implement
> <ron> and you get triple NIH points for a debian specific solution
> <peej> actually, it concerns
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=563386, where the
> suggested +x solution doesn't solve the edge case of dnsmasq installed
> first, then, before a reboot is done, resolvconf is installed next.
> <peej> (package A is therefore resolvconf here, and B dnsmasq that needs
> the restart)
> <ron> doesn't resolvconf let you install hooks to do that?
> <peej> ron, do you mean hooks to specify a restart for all possible
> services that depend on resolvconf ?
> <ron> the +x "solution" would seem to violate all manner of good taste
> conventions
> <ron> well I see /etc/resolvconf/update-libc.d with some scripts in it ..
>   

[1] Ref:http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=563386#31

The suggestions in the discussion can be summarized as follows.

1 (Yoe): Resolvconf dpkg-triggers dnsmasq to restart itself.
2 (cortana): Dnsmasq watches for resolvconf to be installed and restarts 
itself when this happens.
3 (ron): Resolvconf calls a hook script (included in the dnsmasq 
package) which restarts dnsmasq.


These are all valuable suggestions.

First let's consider Yoe's suggestion of using dpkg's trigger 
mechanism.  The trigger mechanism allows maintainer scripts to induce 
the re-running of other packages' postinst scripts.  This could be a 
solution.  Resolvconf's postinst activates a trigger named 
"resolvconf-newly-installed"; dnsmasq, which has registered an interest 
in resolvconf-newly-installed, gets its postinst run with the arguments 
"triggered resolvconf-newly-installed" and this restarts dnsmasq if 
appropriate (i.e., e.g., if configured to run in the present runlevel).  
Is this guaranteed to be race-free when resolvconf and dnsmasq are 
installed at the same time?

Second let's consider cortana's solution.  Also a workable solution and 
one which requires few changes in resolvconf (which I like).  
Disadvantage it that it requires that dnsmasq to poll for [ +x 
/sbin/resolvconf ] so long as /sbin/resolvconf is absent.  That doesn't 
seem very nice.

Third let's consider ron's suggestion.  Packages currently install 
"resolvconf hook scripts" when they want to be informed of changes to 
nameserver information.  Resolvconf hook scripts are not currently 
called when resolvconf is first installed.  For resolvconf to call the 
hook scripts on installation with the meaning "I'm here now" instead of 
the meaning "nameserver information has changed" would be to change the 
semantics of the hook scripts, so in order to implement this suggestion, 
in general changes would be required both to resolvconf and to the hook 
scripts.  This approach implies no more or less work than the first 
approach.

Comments, anyone?  Should I take this question to the debian-devel list?

Please reply to 567059 at bugs.debian.org.
-- 
Thomas