Merging debian version 3.9.1-4.

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

1 files changed, 117 insertions, 0 deletions

diff --git a/debian/NOTES b/debian/NOTES
new file mode 100644
index 0000000..35bc43d
--- /dev/null
+++ b/debian/NOTES
@@ -0,0 +1,117 @@
+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 postifx.
+
+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.
+
+
+postfix@ vs postfix vs postmulti service
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+See https://bugs.debian.org/1088862 - we should revisit how services
+are started.  With systemd, there's no good way to run multiple
+postfix instances within a single service, since systemd wants single
+main process and is confused by multiple such processes.
+
+I think it would be good to have regular postfix.service to start
+just a single default instance.  With all other instances managed as
+their own postfix@foo.service, where foo is a path component after
+/etc/postfix- prefix stripped - path-based because we need to manage
+unnamed instances too, but this restricts directory naming.
+
+When starting as `postfix start' (monolith multiple instances) or
+`postmulti -i foo -p start', these utilities might just execute
+the systemd service transparently instead of trying to run master(8).
+This way, full functionality of postmulti(1) is available to the
+user too, in a sane way, and we can also arrange to enable/disable
+the instances automatically behind the scenes.
+
+It is somewhat difficult to revert back from current multi-instance
+postfix.service to plain postfix.service in postinst.  And since users
+of multi-instance postfix.service, who actually need multiple instances
+managed by systemd, got used to the name `postfix' to refer to multi-
+instance postfix service, it'd be nice to keep this single naming for
+users and for maintscripts too.  Also, users might have other dirs
+besides /etc/postfix-* configured, especially like /etc/postfix/foo
+(within main postfix dir) - these wont be usable.
+
+
+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.
+
+
+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.