On Saturday, 2 June 2012 15:12:59 Kurt Zeilenga wrote:
On Jun 1, 2012, at 5:06 AM, Guillaume Rousse wrote:
> As suggested by Howard, I'm posting here what have been originally
> submitted as an ITS: http://www.OpenLDAP.org/its/index.cgi?findid=7283
> Basically, some openldap header files not installed,
and that should remain so.
> hence considered as private seems to be needed for building out of tree
extensions, such as ppolicy external password:
extensions should be built in-tree.
That is not always feasible. A specific example (in Mandriva) was the smbk5pwd
(with Heimdal support) olverlay, where the "supported" Kerberos server was MIT
(thus in the 'main' repo), but Heimdal was available in the 'contrib'
repository. Since packages in 'main' may not depend on 'contrib', and all
subpackages from on source package must be in the same repository, the options
-don't provide a Heimdal-enabled version (there is already a switch on the
source rpm to enable the Heimdal features, to help people self-packaging, but
it doesn't help much for people using binaries)
-ship the private headers somewhere so that the openldap-smbk5pwd package, in
contrib could be built against the openldap private headers and the require
bits of heimdal.
Like LTB seems to do.
The problem here is you are trying to mix and match. We've never defined
an ABI, we defined an API. Extensions should be built in tree.
If all extensions should be built in-tree, does that imply they should always
be distributed in-tree? The requirement for a password-strength-checking
plugin for ppolicy seems to be quite common ...
Your mistake, me thinks, was asking the packager to distribute
headers... what you should have asked was for them to distribute the
module built from within their OpenLDAP source tree. If they turn you
down, then switch packagers or become one yourself (build everything).
Guillaume already does that (and contributed to some of the work I describe
above), I expect he is trying to get rid of that burden.