On Tue, Nov 23, 2010 at 05:25:34PM -0500, Wietse Venema wrote:
> > 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.
>
> It's probably easiest to simply build and install all extensions,
> with dummy code for support that was not available. Leave it up
> to the package maintainers to split the result into separate bundles
> instead of trying to do their job in Postfix (which we can't anyway
> given the differences).
Yes, that's the idea. Build run-time loadable components (say table
drivers for now) as part of the official Postfix build (stubs where the
module pre-requisites are not met). Put everything in postfix-files as
part of a monolithic Postfix package. The relese-engineering folks
can perform whatever surgery they see fit.
Once we have share libraries, we can begin to think about how to split out
certain pieces as loadable modules. This may mean moving these modules out
of libglobal and libutil into their own libraries, that can be pre-linked
(statically or dynamically), or dynamically loaded.
I don't expect the Makefiles to incur too much damage in this phase
either, rather some complexity will need to leak from the build model
settings in the Makefiles into the compiled code, since the table driver
function pointers are compiled-in in the first case, and loaded
dynamically in the second, so there is some conditionally compiled code
to load said modules.
The pre-linked build should bundle all the table drivers into a single
dynamically linked library, while the dynamically loaded variant will
have a separate module for each, and the table driver library will be
the glue that loads modules on demand.
--
Viktor.
