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 567...@bugs.debian.org.
--
Thomas
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
