Comment 3 for bug 1247803

Hmm, good questions . /me thinks.

The (small) gain is that we omit an unneeded update run prior to the update run that occurs shortly afterwards when the dnsmasq initscript calls resolvconf.

When other things touch resolvconf the update run can't be omitted.

We don't want to skip the update run when ENABLED=0 because in that case the initscript itself does not instigate an update run. If no update run is instigated either in the postinst or in the initscript, and the admin later sets ENABLED=1 and IGNORE_RESOLVCONF=no and does "/etc/init.d/dnsmasq start" and nothing else has instigated an update run in the meantime then dnsmasq starts with an out-of-date /var/run/dnsmasq/resolv.conf which is what we are trying to avoid. So when ENABLED=0 the update run must be done in the postinst even if IGNORE_RESOLVCONF is set.

The code should thus look like this:

    #
    # If ENABLED=0 then the initscript does not call resolvconf, so we do an
    # update run here in order to ensure that /var/run/dnsmasq/resolv.conf
    # is up to date should dnsmasq later be started (with ENABLED=1).
    #
    # If ENABLED=1 then the initscript will call resolvconf and thus instigate an
    # update run, thus updating /var/run/dnsmasq/resolv.conf; but, unless
    # IGNORE_RESOLVCONF is "yes", we have to do an update run here so that
    # /var/run/dnsmasq/resolv.conf is valid before dnsmasq starts.
    #
    if [ "$ENABLED" = "0" ] || [ "$IGNORE_RESOLVCONF" != yes ] ; then
        resolvconf -u
    fi