Victor Duchovni:
> 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
Of course I meant *not run-time configurable*. Like config_directory.
Everything possible should be compile-time configurable.
> > 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.
The "make install/upgrade" will need the option to install headers,
just like manpages and html. We don't need to install all headers,
thanks to the proper hierarchy of library code dependencies.
> > 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.
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).
Wietse
