Random packaging notes


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.  See https://bugs.debian.org/734401


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 postfix.

See https://bugs.debian.org/847242 https://bugs.debian.org/865005
https://bugs.debian.org/864609

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.


chroot
~~~~~~

Debian postfix package always had chroot enabled by default.  Enabling
it in the first place is questionable by itself already, but enabling it
by default is.. difficult, it poses a lot of unnecessary burden to the
users.  High percentage of bug reports in the bts are due to chroot in
one way or another.  We should get rid of this default at least.  Offering
a debconf-level choice might be a good thing, but it is very difficult to
achieve, - maybe only for a new install.  And we have to keep currently
used chroots working, and fix the remaining bugs if possible.

See https://bugs.debian.org/151692 https://bugs.debian.org/1084167 and
numerous bug reports marked with "[chroot]" in the title.

We copy nss stuff to chroot because this is what's used by postfix smtp
client as "native" way for host lookups (smtp_host_lookup).  By default
it uses internal dns routines directly, which utilizes res_* functions.
Also, various networking maps might use nss host lookups, but these are
better to be handled with proxy: map type.  Glibc does not need libresolv
anymore.  And picks up changes to resolv.conf immediately on next lookup.

#572841 says /dev/random and /dev/urandom are needed in chroot jail
to run ldaps.  Is this true still?  Are these device files needed for
something else?  In 3.9.1-5, I stopped creating /dev/random in chroot.


rmail
~~~~~

Do we need rmail binary (comes from sendmail package) and a working uucp
entry in master.cf in 2025?  Not that it requires much though.
