Full_Name: Quanah Gibson-Mount Version: RE25 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.239) It's currently difficult for downstream packagers to create a working development package as some items required to build external modules are only included what are considered "private" headers, such as slap.h (See ITS#7283). SLAP_CB_{BYPASS,CONTINUE} are examples of items that are contained in slap.h that are potentially required for building external modules. IIRC, it's also been discussed previously to rename "ldap_pvt.h" to "openldap.h" to indicate it's ok to package this header file in a -devel package (I could have the initial header name incorrect, it's been a while).
quanah@openldap.org wrote: > Full_Name: Quanah Gibson-Mount > Version: RE25 > OS: N/A > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (47.208.148.239) > > > It's currently difficult for downstream packagers to create a working > development package as some items required to build external modules are only > included what are considered "private" headers, such as slap.h (See ITS#7283). > SLAP_CB_{BYPASS,CONTINUE} are examples of items that are contained in slap.h > that are potentially required for building external modules. > > IIRC, it's also been discussed previously to rename "ldap_pvt.h" to "openldap.h" > to indicate it's ok to package this header file in a -devel package (I could > have the initial header name incorrect, it's been a while). This discussion is a bit awkward. OpenLDAP is an open source project. What we provide is a distribution of source code. It was never intended to be sliced and diced into individual binary packages. If you're developing modules for OpenLDAP, you're expected to have a complete OpenLDAP build tree in which your modules reside. Modules meant to run inside slapd are by definition *internal* - they are running inside slapd after all. The fact that they're written and maintained by 3rd parties doesn't change this. Header files marked "private" mean they're only for internal use within an OpenLDAP build tree. Applications that are generic LDAP clients should only use the public APIs. We can still discuss formally making some OpenLDAP-specific APIs public, but that should probably be done on a case by case basis. LDAP is supposed to be interoperable; we should not encourage broader use of OpenLDAP-specific APIs that rely on details of OpenLDAP's internal implementation. If they have no particular dependency on internals, then we may safely expose them. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Fixed in 6a5e30674b63b17587738ba9a3d1ea3633c33fb1 *** This issue has been marked as a duplicate of issue 8671 ***