Random notes for packaging

debconf
~~~~~~~
Debconf handling is done in a wrong way.  It should feed its initial
values from the live system (from actual main.cf, etc files) instead
of using values previously stored in the database, - unless there's
no initial configuration found, in which case default values stored
in the debconf should be used.  This avoids re-setting configuration
to debconf values on every upgrade, - we have multiple bugs about
that.

alias handling
~~~~~~~~~~~~~~
up to 3.9.1 postfix postinst hardcoded hash:/etc/aliases as the only
place for aliases, created this file on every upgrade (despite it
might be unused or moved), and adds (or tries to add) root alias to
this file too.  It might as well take a look at $alias_maps.

Root alias handling (root_address debconf question) logic is wrong:
it adds root alias only if set by debconf, when either of the two
conditions met (simplifying): either /etc/aliases does not exists,
or it is a new install (not upgrade).  But root_address debconf
question is of "medium" priority, while default priority when
first run is "high", so this question is not seen by the user.
When re-configuring it, /etc/aliases exists and it is not a new
install anymore, so it is not added.

newaliases
~~~~~~~~~~
In debian postfix package up to 3.9.1, it was used to run newaliases
if alias database contains a map type being registered.  This is kinda
pointless, -- yes, it helps in a situation when the user configured
a new map type for alias_database which is not installed on the target
system, -- now, alias database will be built automatically at map install
time.  But this isn't a common situation, and the user can run newaliases
manually after observing errors in the logs.  And it is still broken,
because alias database might contain other map types, in which case
newaliases will fail and the installation will stop too.  A correct
solution would be to add a trigger to the main postfix package and try
to rebuild aliases.  Or better yet, just remove whole thing and only
try to run newaliases once at new install, and just tell user to re-run
it manually if failed - since adding this automatic complexity is
difficult (to get right) with no visible gains.

There might be another case when we may want to run newaliases during
upgrade: when file format has changed for some database.  But this
should be handled for all maps, not just aliases, and for all instances,
and it is dependent on other packages, not on postifx.

Complex newaliases handling has been removed in 3.9.1-3, - we now
try to run newaliases only once when we know we modified /etc/aliases,
at the end of postfix.postinst script, and if that failed, just warn
user and continue.  No need to try to be smart here.
