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