Re: LDAP library version number

[Jens Vagelpohl <jens@dataflake.org>]

> > > 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.

jens

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