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, hence considered as private seems to be needed for building out of tree extensions, such as ppolicy external password: checker (http://ltb-project.org/wiki/documentation/openldap-ppolicy-check-password).
According to howard, at least one of them (slap.h) seems to be mostly useless in this specific case, and could be avoided. The other one, tough (portable.h) seems unavoidable...
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.
checker (http://ltb-project.org/wiki/documentation/openldap-ppolicy-check-password).
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.
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).
-- Kurt
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
On Jun 4, 2012, at 5:03 AM, Buchan Milne wrote:
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?
No.
My point was more that building of extensions to slapd depend on exactly how slapd was built. That is, by "in-tree", I meant "with specific knowledge of the particular slapd source and how it was built". That knowledge doesn't require the extension to be "in-tree" but to have knowledge of the source and how it was built.
The requirement for a password-strength-checking plugin for ppolicy seems to be quite common ...
Yes.
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.
There's more than one way to rid yourself of your burdens.
-- Kurt
Regards, Buchan
-
Buchan Milne -
Guillaume Rousse -
Kurt Zeilenga