[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: LDAP library version number

so that it would be very bad to link (ln -s) /usr/lib/liblber-2.2.so.7.0.1 to /usr/lib/liblber.so.2 ?

It certainly would not be all that wise.

So what it the wise solution !? I just compiled & packaged openldap-2.2.11 and I still get the dependencies problem on "liblber.so.2 is needed by (installed) php-ldap-4.2.2-18.3" etc ...
Does this mean I need to recompile all pakages depending on liblber.so.2 &libldap.so.2 ? or I can dream on a easier solution ? the ABI is incompatible with old packages or it just adds "new features" , in that case I don't see why generating a liblber.so.2 in addition (as a copy or link) to the actually make install generated liblber-2.2.so.7 would be bad advice ?
what do you advice ?

I used to be upset that the library naming changed, but no more. It really does not make much sense to compile the newer package and then force the newer libraries in place of the older ones. You will not be able to guarantee that everything will work as expected, *period*. Even if you get the library name correct and your RPM installs cleanly.

In reality, if you insisted on replacing the system default OpenLDAP package the only way to guarantee that things work as before would be to recompile the dependent packages. That is unpractical in most cases, though.

I believe the only acceptable solution would be to create RPM packages that stay separate from the system-installed packages. You could make them install into /usr/local or some other place of your choosing. On one of the machines I manage I opted for leaving the RH9 OL 2.0.27 package in place to satisfy existing dependencies, but the OpenLDAP server on there is hand-compiled and installed into /usr/local.


Attachment: smime.p7s
Description: S/MIME cryptographic signature