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 were:

-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.

> > checker

> > (http://ltb-project.org/wiki/documentation/openldap-ppolicy-check-passwo

> > rd).

>

> 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 private

> 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.

Regards,

Buchan