Comment 6 for bug 1247803

We certainly don't want to run "resolvconf -u" too few times. That is the bug.

It causes no logical malfunction to run "resolvconf -u" too many times, but doing so is not efficient. When a resolvconf update occurs then all the scripts in /etc/resolvconf/update.d/ get run. If a "heavy" update script is present (one that copies files, reconfigures things and/or restarts services, etc.) then the update can take a significant amount of time. In that case it's bad to do an extra, unnecessary update. And I think it's ugly to do two updates in a row if one is sufficient.

> The proposed conditional only suppresses running resolvconf -u
> if ENABLED=1 and resolvconf is not being used (ie IGNORE_RESOLVCONF=yes).
> Is this really such a common case that adding complexity to get the minor
> optimization of not running resolvconf -u is worth it?

You have a point there. Perhaps it is, perhaps it is not worth the added code complexity in the postinst. The maintainer will be the judge.

> Also, doesn't your argument about ENABLED=0 later being changed
> to ENABLED=1 also apply to IGNORE_RESOLVCONF=yes later being
> changed to IGNORE_RESOLVCONF=no?

No, I don't think it applies. In the ENABLED=0 case, resolvconf doesn't get run by the dnsmasq initscript. So unless the postinst does "resolvconf -u" there is nothing to ensure that if dnsmasq is later restarted with ENABLED=1 and IGNORE_RESOLVCONF=no then /var/run/dnsmasq/resolv.conf will have been written. In the ENABLED=1 IGNORE_RESOLVCONF=yes case resolvconf does get run in the dnsmasq initscript and /var/run/dnsmasq/resolv.conf gets written (even though it won't be used). So if dnsmasq is later restarted with ENABLED=1 and IGNORE_RESOLVCONF=no then /var/run/dnsmasq/resolv.conf is ready.