5:06 a.m.
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...
--
BOFH excuse #238:
You did wha... oh _dear_....
6:12 a.m.
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.
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
5:03 a.m.
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
9:51 a.m.
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
4018
days inactive
4021
days old
3 comments
3 participants
participants (3)
-
Buchan Milne -
Guillaume Rousse -
Kurt Zeilenga