On Tue, Nov 23, 2010 at 03:12:02PM -0500, Wietse Venema wrote:
> For compile-time libraries I think that the only practical option
> is not to make it configurable at all. Install them on the system
> library search path, such as
>
> /usr/local/lib shared objects
> /usr/local/include/postfix header files
If we want to use postfix-files (which I do) to describe where everything
gets installed, including the libraries, then we need a parameter visible
at least at package creation time that determines the library location.
Also, I can't install in /usr/local/lib, ... for AFS all the bits have
to go into the vast global namespace:
/afs/deep-path/postfix/<version>/common/abi-neutral-files
/afs/deep-path/postfix/<version>/.exec/<abi>/abi-specific-files
> Without header files the objects would be worthless.
The header files are needed to build new dynamic objects, these can also
be built together with the Postfix source code and then distributed
separately. I doubt that Debian ships the headers, likely just the
dynamic modules and the shared libs they need.
> Now the problem is that every d*mned internal Postfix API becomes
> a published interface. That is not where I want to go.
I think the goal is not so much to support all possible 3rd-party addons,
as to allow an O/S release-engineering team to deliver a modular Postfix,
with some optional modules (e.g. table drivers) so they don't have to
build the kitchen sink into every Postfix executable.
So if we are supporting what Debian are doing, it is just breaking
down the existing code-base into bite-size pieces, rather than
exposing internal APIs as a development platform.
In that light, the headers don't get installed, and the API is still
internal, but supports modular packaging. We would then compile all
the supported table driver modules once we get past the initial
dynamic linking hurdles. Then release engineers can split out
some modules for separate packaging, but there is no more invitation
for 3rd-party code, then there is when you make the source-code
available.
--
Viktor.
