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.
