Re: Regenerating package configuration non-interactively?

[Brian Candler <b.candler@pobox.com>]

On 30/09/2019 14:23, Jonas Smedegaard wrote:

The missing piece is /var/lib/dpkg/postfix/config

Thanks - presumably you mean /var/lib/dpkg/info/postfix.config ?

root@foo1:~# find /var/lib/dpkg -name '*postfix*'
/var/lib/dpkg/info/postfix.prerm
/var/lib/dpkg/info/postfix.list
/var/lib/dpkg/info/postfix.preinst
/var/lib/dpkg/info/postfix.conffiles
/var/lib/dpkg/info/postfix.postinst
/var/lib/dpkg/info/postfix.config
/var/lib/dpkg/info/postfix.templates
/var/lib/dpkg/info/postfix.shlibs
/var/lib/dpkg/info/postfix.postrm
/var/lib/dpkg/info/postfix.triggers
/var/lib/dpkg/info/postfix.md5sums

AFAICS this goes through a series of states prompting for individual settings from the frontend.  It explicitly does nothing except skip to the next state if the frontend returns code 30, meaning the setting was invisible/skipped.  e.g. for /etc/mailname:

      $noninteractive = (((input("high", "postfix/mailname"))[0]) == 30);
      if ($noninteractive) {
        $topstate = "relayhost";
      } else {
          # error checking
          my $mailname = lc(get("postfix/mailname"));
          fset("postfix/mailname", "changed", "true");
          ...

Therefore, is the simple answer that the use case I described is not supported?

I guess I could uninstall and purge the package, preseed and then reinstall - but that feels like a huge hack.

Alternatively, I wonder if it's plausible to make a new frontend like 'noninteractive' which returns the current values of all settings (as if confirmed by human), instead of skipping them with code 30?

Regards,

Brian.