On Wed, Sep 21, 2011 at 11:29:49AM +0200, Dag-Erling Sm??rgrav wrote: > Kostik Belousov <[email protected]> writes: > > Yes, the question of maintanence of the OpenLDAP code in the base > > is not trivial by any means. I remember that openldap once broke > > the ABI on its stable-like branch. > > That's irrelevant. Our own renamed subset of OpenLDAP would only be > used by our own code, primarily nss_ldap and pam_ldap, and would be > updated when and only when we decided that it needed updating, not every > time a new OpenLDAP release shipped. We did this successfully with > expat (libbsdxml), and there's no reason why it wouldn't work with > OpenLDAP. > > > Having API renamed during the import for the actively-developed > > third-party component is probably a stopper. I am aware of the rename > > done for ssh import in ssh_namespace.h, but I do not think such > > approach scale. > > The entire point of ssh_namespace.h is to minimize the amount of changes > required. Actually, when I say minimize, I mean "reduce to zero", and > the file itself is autogenerated, except for lining up the columns, > which I do manually. I don't know why you think it doesn't scale. > > I don't think we have anything to gain by writing our own LDAP library. > Firstly, new code means new bugs, and this is security-critical code. > Secondly, any LDAP client library we wrote would have to have an API > that closely paralells OpenLDAP's; otherwise, we would also have to > rewrite nss_ldap and pam_ldap.
I do not think that we would benefit from writing our own LDAP library either. But I also doubt that importing ldap support in base would offer any advantages in sum.
pgpO3YFtOcZvN.pgp
Description: PGP signature
