In response to maintainer feedback, I have cleaned up Postfix
shared-library and database plugin support. The result of several
iterations is postfix-2.12-20140625. See RELEASE_NOTES and INSTALL
for an updated introduction.

What has changed:

- Non-executable files are no longer installed in $daemon_directory.
Their location is specified with the meta_directory parameter which
has the same default as config_directory, but this can be changed
if backwards compatibility is desired. See postconf(5).

- Dynamically-linked library and plugin file names now end in .so.
Using the Postfix release version as a suffix for shared-object
file names was a mistake that broke conventions and violated
assumptions.  Unlike system libraries that implement a public API
that is backwards compatible with earlier versions, Postfix libraries
implement a Postfix-internal API that changes incompatibly.

- To reduce parameter sprawl I eliminated the plugin_directory
parameter.  All shared objects, both libraries and database plugins,
are installed in $shlib_directory. 

- The file dynamicmaps.cf supports absolute database plugin pathnames
for backwards compatibility, so the plugins can still be installed
anywhere.  As part of the cleanup, the Postfix release version
suffix was removed from the dynamicmaps.cf and dynamicmaps.cf.d
pathnames.

- Postfix shared libraries and database plugins are now installed
in a directory that contains only Postfix-related files. Installing
these files in a public directory such as /usr/lib or /usr/local/lib
is explicitly not supported. Also, linking these files into other
programs is explicitly not supported. As mentioned earlier, the
files implement a Postfix-internal API that changes incompatibly.

- To avoid prograam/library mismatches when people like me upgrade
a running Postfix system, I tried in vain to implement some usable
equivalent of "make makefiles shlib_directory='/some/where/$mail_version'".
There was no way to get a consistent result with different make
implementations.  The solution that I settled on, "make makefiles
shlib_directory='/some/where/MAIL_VERSION" works around this with
simple string substution.

- As documented in the file INSTALL, the MAIL_VERSION string
substitution feature also works for parameter values on the command
line with "make install", "make upgrade" and "make package", and
it also works for other configuration parameters.

        Wietse

Reply via email to