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

Re: Library version naming confusion

Apologies if this is a FAQ somewhere. I am noticing that when I build
OpenLDAP 2.2.5 on RedHat 9 the libraries are not named...

lib<foo>.so.2.x.x

but they are...

lib<foo>.so.201.x.x

I am attempting to create a set of RPMs but on RH9 everything is keyed
to "lib<foo>.so.2", so the RPM isn't usable. Does anyone know how I can
influence this naming behavior, and do it "the right way"?

For reference and so that people can find it in the archives, here's what I did to create a "working" set of RPMs. "Working" because I am sure I missed something somewhere, and what I did is likely to offend some peoples' sensibilities ;)

Starting point is the last RedHat9 OpenLDAP SRPM (2.0.27-8) and the spec file included therein.

- Change version number in the spec file to 2.2.5 and include the OpenLDAP 2.2.5 tarball

- Change the BerkeleyDB version in the spec file to 4.2.52 and include the BerkeleyDB 4.2.52 tarball

- Remove references to all patches applied to the OpenLDAP source tree, this is Patch0 through Patch10 and Patch26 (most of them do not work, anyway)

- Remove packaging instructions for "ldapfriendly" and help files ending in ".help", those seem to have been deprecated/removed

- Add packaging instructions for the folder /usr/share/openldap/ucdata and all files underneath (those are new)

- And for the piece de resistance, the bit that will create library names conforming to RedHat expectations, include the following patch file and add instructions for it to be applied in the spec file. Everyone whose toe nails curl upon seeing this, let me know what all can break by doing it:

--- openldap-2.2.5/build/version.var 2004-01-22 20:35:51.000000000 -0500
+++ openldap-2.2.5.fixed/build/version.var 2004-02-21 21:19:16.000000000 -0500
@@ -17,5 +17,5 @@
ol_minor=2
ol_patch=5
ol_api_inc=20204
-ol_api_lib=202:4:1
+ol_api_lib=4:5:2
ol_release_date="2004/01/22"

After all that you can build binary RPMs. Running "make test" in the various build directories left behind by the RPM build process works flawlessly and the resulting binary RPMs replace existing 2.0.27 RPMs cleanly.

DISCLAIMER: Don't blame me if you build and install these RPMs and your system becomes unstable/unusable...

jens

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