[Date Prev][Date Next]
Re: LDAP library version number
- To: Openldap list <openldap-software@OpenLDAP.org>
- Subject: Re: LDAP library version number
- From: Jens Vagelpohl <email@example.com>
- Date: Wed, 28 Apr 2004 13:34:24 -0400
- In-reply-to: <408FFDEE.firstname.lastname@example.org>
- References: <4022359B.email@example.com> <firstname.lastname@example.org> <4023A1BB.email@example.com> <firstname.lastname@example.org> <4030E370.email@example.com> <firstname.lastname@example.org> <4034B17D.email@example.com> <firstname.lastname@example.org> <4034C84F.email@example.com> <firstname.lastname@example.org> <4034D900.email@example.com> <firstname.lastname@example.org> <403C6A23.email@example.com> <404073BC.firstname.lastname@example.org> <404748F3.email@example.com> <firstname.lastname@example.org> <40631ABF.email@example.com> <firstname.lastname@example.org> <406986F9.email@example.com> <firstname.lastname@example.org> <408FFDEE.email@example.com>
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,
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.
Description: S/MIME cryptographic signature