Unless there is a related RC bug there, I don't think it's gonna matter when the change is to get it in sarge (i personally have not seen any RC bugs though...)
On 30/05/05, Torsten Landschoff <[EMAIL PROTECTED]> wrote: > Hi *, > > People following the OpenLDAP packages might remember this change: > > openldap2 (2.1.30-7) unstable; urgency=high > > * Stephen Frost <[EMAIL PROTECTED]> > + debian/move_files: make libldap a symlink to libldap_r, as carrying > two versions of this library around is more trouble than it's worth, > and can cause glorious segfaults down the line > (closes: #306258, #302296, #306546) > > At first sight this looked (for me) like making sense and having no > negative implications. Of course reality was different - ldconfig had > problems setting the right symbolic links. > > Today I found out the reason. It was not that it just removes symbolic > links it can't make sense of. Rather the problem is that the SONAME of > that library now does not match the name anymore. > > libldap.so.2 used to have the SONAME libldap.so.2 as you would expect :) > Now the libldap.so.2 is a symlink to libldap_r.so.2 which has SONAME > libldap_r.so.2. > > I wonder which implications that could have when applications are > linking to libldap.so.2 (as the SONAME is no longer found). > > Therefore I thought it might be a good idea to relink libldap_r.so.2 > using libtool and create libldap.so.2 with matching soname. Now I wonder > what will happen if some program decides he wants to link both > libldap.so.2 and libldap_r.so.2. > > Suggestions how to fix that for real before getting sarge out of the > door with this risk that I don't feel I can estimate? > > Thanks! > > Torsten > > > BodyID:25699729.2.n.logpart (stored separately) > > -- N Jones
