On Wed, 2012-10-31 at 09:01:23 -0400, Wietse Venema wrote:

> Ralf Hildebrandt:
> > * Sahil Tandon <postfix-users@postfix.org>:
> ... 
> > >   test -n "`$POSTCONF -c $config_directory -n smtpd_relay_restrictions`"
> > > 
> > > With this, the forward compatibility shim would only trigger if
> > > smtpd_relay_restrictions does not appear in an existing main.cf, while
> > > explicitly empty settings of the parameter would be preserved during an
> > > upgrade.
> > 
> > I think your proposal is good. I encountered the same behaviour (I
> > first set smtpd_relay_restrictions to an empty value and THEN upgraded)
> 
> OK, I have changed this.

Great, thank you!

> BTW I duplicated that test from the inet_protocols compatibility shim.
> That parameter is usually not set to the empty value but the shim has
> the same problem.

Aye. I have a separate question that is tangentially related, so I hope
that it is OK to broach without spawning a separate thread.

Some background: upon deinstall, unaltered files installed by a FreeBSD
package are supposed to be deleted.  In the context of Postfix
configuration files, this is done by comparing, for example, the stock
main.cf in $daemon_directory with its analogue in $config_directory, and
only deleting the latter if the two match.  These two files are
identical after a fresh install of a pre-built Postfix package, so
uninstalling Postfix via the package management framework results in the
expected deletion of all main.cf files.

The issue I have with the smtpd_relay_restrictions compatibility shim is
that it is triggered even on fresh install of a pre-built Postfix
package.  This is because the main.cf placed in $config_directory does
not include a smtpd_relay_restrictions definition, which is therefore
added by the package management system that has historically called the
post-install script with the 'upgrade-package' argument. So, as of the
latest 2.10 snapshot, the two main.cf's no longer match after a fresh
package install.

I understand this is not a Postfix issue, but I would appreciate if
other package maintainers (or anyone else who is willing to opine!)
could share how they handle this.  I initially thought to append a
default smtpd_relay_restrictions definition to the stock version so that
the two main.cf files would match following a fresh install, but then I
wondered if that could cause unwelcome consequences.  Is there a more
canonical approach to all this?

BTW, there is no similar issue with the inet_protocols shim because that
parameter is explicitly defined in the stock main.cf.

-- 
Sahil Tandon

Reply via email to