[Resolvconf-devel] resolvconf-event

Thomas Hood jdthood at gmail.com
Thu May 19 08:35:38 UTC 2011


/me gives this more thought

What we really want is for all suppliers of nameserver information
(SNIs) that are already installed and running before resolvconf
is installed to be notified that resolvconf has been installed so
that they can send their nameserver information to resolvconf.

Sounds simple.  The devil, however, is in the details.

I have introduced a dpkg trigger.  It gets activated in the postinst.
It is useful for one reason that is independent of the need
described above: it allows us to postpone enabling updates
until after the "postinst configure" phase.  So any nameserver
information that comes in during this phase gets accumulated
and one update occurs at the very end.  No multiple update
runs.  For this reason alone the dpkg trigger will remain.

My idea was that this trigger would also be used by other
packages to know when resolvconf had been installed or
uninstalled.  I now see two significant disadvantages to this.
(1) The other package gets notified in the "postinst triggered"
phase which is the phase where resolvconf enables updates.
If the other package does "postinst triggered" after resolvconf
does then the result is multiple update runs.  (2) Too many
packages get triggered.  If dnsmasq (for example) is installed
in the same dpkg run as resolvconf then it sends its name-
server info to resolvconf at "postinst configure" time; but
then it gets triggered and sends its info again at "postinst
triggered" time... unless it keeps track of what information it
has already sent.  Note that dnsmasq does need to register
interest in the trigger in case it is installed in an earlier dpkg
run.

The only packages that need to be notified are ones that
are configured before resolvconf is unpacked and that are
still configured when resolvconf is configured.

This leads me to make the following proposal.

Each SNI supplies a hook script in /etc/resolvconf/install.d/
named like itself.  Resolvconf "preinst install" takes the list of
these files and filters it down to a list of (already) configured
packages.  It writes this list to a temporary file.  Resolvconf
"postinst configure" reads in the list and filters it (again) to
remove packages that are no longer configured.  Then it
executes each file in the list with the argument "install".

The prerm does the same and executes each file in the list
with the argument "remove".

Reactions?

One thing I need to do is check whether or not it's legal for
maintainer scripts to check the states of other packages by
some means such as this:

dpkg-query -W -f='${Status}\n' "$PKGNAME" 2>/dev/null | grep -siq
'^[[:alpha:]]\+ [[:alpha:]]\+ installed$'

-- 
Thomas



More information about the Resolvconf-devel mailing list