Re: LDAP library version number

["jehan.procaccia" <jehan.procaccia@int-evry.fr>]

Jens Vagelpohl wrote:

> 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

OK this is what I finally did.
I built a relocatable RPM package of openldap which by default install 
everything ( openldap 2.2.14 + db 4.2.52) in /usr/local but which can be 
moved to any directory at rpm installation time by using the --prefix 
option, example:
[root@corbeau /usr/src/redhat/RPMS/i386]
$ rpm -ivh --prefix=/usr/local/openldap-2.2.14-1 openldap-*2.2.14-2*.rpm
or $ rpm -ivh --prefix=/opt , anything you want, /usr/local will be 
replaced by what you put in --prefix.

Now I can have the openldap system wide installation that comes with the 
distribution I use and the latest version of openldap I wish to run 
without conflict ;-)
On my Fedora Core 2 :
$ rpm -qa | grep openldap
openldap-2.1.29-1
openldap-2.2.14-2
openldap-servers-2.2.14-2
openldap-clients-2.1.29-1
openldap-servers-2.1.29-1
openldap-clients-2.2.14-2
openldap-devel-2.2.14-2
openldap-devel-2.1.29-1

If you wish to use these packages I strongly recommend to read the 
REAME-jehan.txt file from my openldap source RPM package to see in 
details how to install, use ,and maybe rebuild for other distributions 
this package source .
Here where you can find the rpm binaries for fedora core 2:
http://www.int-evry.fr/mci/user/procacci/SRPMS/FC2/
and the Sources:
http://www.int-evry.fr/mci/user/procacci/SRPMS/

Although there are many things that needs to be enhance in the SPEC 
file, I hope this might help others using rpm based distribution and 
strugling with rpm conflicts . Again if there's a central and public 
repository for openldap packages, and if others want to contribute 
please let me know.

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