Full_Name: Russ Allbery Version: 2.4.7 OS: Debian GNU/Linux URL: Submission from: (NULL) (171.66.157.14)
One of the challenges of handling core system libraries like OpenLDAP in the context of a packaged distribution is handling library transitions when the SONAME of the library changes (such as between 2.3 and 2.4, and presumably between 2.4 and 2.5). It's rarely possible to rebuild every package at the same time against the newer libraries (particularly since there are dependency chains that often require one package go first before another can be rebuilt), let alone all of the user software that's outside the space managed by the distribution. Because of that, both the old and new library usually have to co-exist for at least a brief period on many systems, with some binaries linked against the old version and some against the new version, until the upgrade is complete.
This is, fundamentally, the problem of the distribution and not the problem of the OpenLDAP team. However, one thing that, from a distributor perspective, helps considerably with transitions like this is if the upstream library distributor uses symbol versioning on those platforms that support it (primarily Linux and Solaris, and possibly -- I have no personal experience -- the *BSDs). If symbol versioning is used for the libraries, the 2.3 and 2.4 libraries can be loaded into the same namespace and won't conflict with each other, since the programs and other libraries will bind to the version against which they were compiled.
So, basically, this is a feature request: would it be possible to add symbol versioning to the libldap and libber libraries? Very simple symbol versioning (just assigning one version to all public symbols) would be sufficient to make these sorts of transitions much easier. I'm happy to help provide information and Makefile glue to do this if it's desirable; I've done it in a portable way with several other libraries in packages I maintain.
Please feel free to tell me I should move this to a post to openldap-technical or somewhere else; I know it's sort of borderline between an ITS and a library usage discussion.