[SOLVED] Proper definition of spec file for upgrading libraries

Issue

There is a library package that I'm responsible for distributing. Some time ago, the build system was switched from our home-baked Makefile to using GNU Autotools. As such, using libtool, we now have the ability to easily manage multiple installed versions of the library. Having switched to RPM for distribution, I'd like to know how I can "doctor" the spec file to refrain from completely uninstalling previous versions when upgrading.

For example, after installing version 1.0.0 of a dummy library project I have

[afalanga@afalanga4 libtest]$ ls /usr/lib64/libaby*
/usr/lib64/libabyss.a   /usr/lib64/libabyss.so    /usr/lib64/libabyss.so.0.0.0
/usr/lib64/libabyss.la  /usr/lib64/libabyss.so.0

Then, after sudo yum localupdate .... I have the following:

[afalanga@afalanga4 libtest]$ ls /usr/lib64/libaby*
/usr/lib64/libabyss.a   /usr/lib64/libabyss.so    /usr/lib64/libabyss.so.0.0.1
/usr/lib64/libabyss.la  /usr/lib64/libabyss.so.0

Of course, as a libtool-produced library the only "real" files are: libabyss.a, libabyss.la and libabyss.so.0.0.1. What should be done in the spec file to ensure that libabyss.so.0.0.0 stays after libabyss.so.0.0.1 is installed? The symbolic links will be take care of accordingly.

Solution

There is no real way to do what you're trying to do because the symlink that is used to load the library is managed by ldconfig and are based on the SONAME of the library (see my post on the topic. So even if you kept .so.0.0.1 nothing would ever be using it.

If you want them for compatibility because they may be different ABIs, then you'll have to make sure the versioning is done correctly but it doesn't seem to be the case from what I can read.

Other than that, I'm not sure if RPM has any special case to keep multiple version of a given library in these cases, because there should really be no need for that to happen.

Answered By - Diego Elio Pettenò

Answer Checked By - Mildred Charles (WPSolving Admin)