[Date Prev][Date Next]
Re: LDAP library version number
- To: Jens Vagelpohl <firstname.lastname@example.org>
- Subject: Re: LDAP library version number
- From: "jehan.procaccia" <email@example.com>
- Date: Thu, 08 Jul 2004 15:54:59 +0200
- Cc: Openldap list <openldap-software@OpenLDAP.org>
- In-reply-to: <4A9E853F-993A-11D8-A9DF-000393D58818@dataflake.org>
- References: <4022359B.firstname.lastname@example.org> <email@example.com> <4023A1BB.firstname.lastname@example.org> <email@example.com> <4030E370.firstname.lastname@example.org> <email@example.com> <4034B17D.firstname.lastname@example.org> <email@example.com> <4034C84F.firstname.lastname@example.org> <email@example.com> <4034D900.firstname.lastname@example.org> <email@example.com> <403C6A23.firstname.lastname@example.org> <404073BC.email@example.com> <404748F3.firstname.lastname@example.org> <email@example.com> <40631ABF.firstname.lastname@example.org> <email@example.com> <406986F9.firstname.lastname@example.org> <email@example.com> <408FFDEE.firstname.lastname@example.org> <4A9E853F-993A-11D8-A9DF-000393D58818@dataflake.org>
- User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510
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.
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
$ 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
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:
and the Sources:
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