Why is it necessary to run 'dpkg-reconfigure' on bodged installs?

Question

I recently became acquainted with the restorative power of dpkg-reconfigure following a bodged installation of the GNU mailutils package. At the end of the installation process a dialog (ncurses?) appears prompting the user to make choices and fill in some blanks. That's all well and good, and I suppose if you're proficient enough, you simply avoid making any mistakes in the "post-install configuration dialog", or PICD as I'll call it in the sequel.

I'm not proficient, and needed to re-run the 'PICD'. Not yet being acquainted with dpkg-reconfigure, I assumed that it was necessary to un-install, then re-install. But when I did that, the installation completed - but the 'PICD' did not re-appear. I tried a reboot, but still no 'PICD'!?!

Eventually, someone clued me about dpkg-reconfigure, but dpkg-reconfigure mailutils also failed to restore the 'PICD'. It turned out that it was not mailutils that needed to be reconfigured - it was postfix - the MTA. This took a while to sort out because the Debian packager for mailutils cleverly hid postfix under an innocuous "virtual package" called default-mta. And so the magic required to get a second chance for re-configuration was: dpkg-reconfigure postfix. This discovery enabled my trial-and-error approach to configuration, and I finally completed it.

But this has raised a question or two for me:

1. What is it that disables presentation of the 'PICD' on subsequent installations? I mean, how does the install script know that the user has already seen the 'PICD'? Is there some value recorded & saved by the installer to prevent the 'PICD' replay?

2. Why does the installer disable subsequent presentations of the 'PICD' (without the dpkg-reconfigure incantation)? What is the point of that actually?

Answer 1

1. The postfix package uses debconf for its configuration. You can think of this as a kind of registry in Debian; it’s used by most packages which need configuration during installation. You can see the values it currently stores by running debconf-get-selections. A package can determine during installation whether a value it expects has already been stored in the debconf database.

2. Once a value is set in debconf, general practice is to not show the corresponding dialog during package installation. This avoids asking the user the same question multiple times, in particular every time a package is upgraded (this is strongly recommended by Debian Policy). It also allows packages to be pre-configured, so they can be installed with custom settings without user interaction; this is common practice for automated installations where many systems need to be configured in the same way.

As you determined, if a configuration setting needs to be amended, the best way to proceed is to run dpkg-reconfigure. Another possibility is to purge the affected package, and re-install it: if nothing else depended (even weakly) on default-mta or postfix, sudo apt purge --autoremove mailutils would have cleared everything without your having to determine that postfix was the package actually at fault. (In practice, you’d have to purge postfix itself since many packages will prevent default-mta from being an auto-removal candidate, including unattended-upgrades or cron.)