exiv2-libs not backwards compatible

Latest response

Hi!

I have a third-party RPM installed which is linked against libexiv2 (exiv2-libs). When trying to do a yum upgrade towards the 7.5 package set, I am greeted with the following error:

--> Finished Dependency Resolution
Error: Package: *witheld* (installed)
           Requires: libexiv2.so.12()(64bit)
           Removing: exiv2-libs-0.23-6.el7.x86_64 (@rhel-7-server-rpms)
               libexiv2.so.12()(64bit)
           Updated By: exiv2-libs-0.26-3.el7.x86_64 (rhel-7-server-rpms)
              ~libexiv2.so.26()(64bit)
Error: Package: gnome-classic-session-3.26.2-3.el7.noarch (rhel-7-server-rpms)
           Requires: gnome-shell-extension-top-icons = 3.26.2-3.el7

It seems that the new package version overwrites the old so file, instead of including a backwards compatible version. How do I fix this? I thought common practice was to create a new libs package whenever the so file version changed, to allow old software to be installed (and updated eventually)?

Responses

Hello Peter,

Some developers put version lock in the rpm metadata. So it might be that you need to upgrade the third-party rpm first and then you might be able to upgrade RHEL 7.4 to RHEL 7.5

Regards,

Jan Gerrit

Yeah, the third-party RPM does depend on libexiv2.so.12 (since the SO version is updated, the new version is apparently not ABI compatible). On my Debian systems, such an incompatible SO version usually comes as a new package, allowing them to be installed side-by-side, I am a bit baffled by Red Hat not doing so for RPM. This means that third-party software can't really link to anything if you want to be able to upgrade properly :-/

Stumbled upon the same problem. Problem is that libexiv2 does not provide (minor) version independent symlinks like other libraries do. It seems that libexiv2 from 0.23 to 0.26 is a minor update that should not break dependend packages.

BTW why did exiv2-libs-0.23 provide libexiv2.so.12 instead of libexiv2.so.23 ? There is some inconsistency here, maybe this was done because of similar problems with updates ? Which version of libexiv2 was included in RHEL 7.3 ?

For example lipvpx provides symlink lipvpx.so.1 libvpx.so.1 -> libvpx.so.1.3.0

Well, the version number change does indicate that the ABI is incompatible, so a symlink will not solve the issue. A compatibility package is needed.

Without having the different ABI versions in different packages means that third-party packages cannot be made compatible with both RHEL 7.0--7.4 and 7.5 at the same time. Or, currently, with both CentOS (with is at 7.4 level) and RHEL (which is at 7.5) simultaneously.

Yes this is a major issue. I have now rebuilt my depending package, now can't update systems that are stuck to 7.4...

We are using http://openbuildservice.org/ to build our packages which introduces another issue. OBS only has one RHEL-7 profile as a base for builds (they still install exiv2-libs-0.23-6.el7 if you define it as a dependency).

If RedHat allows breaking changes on minor release updates, there would be a need for separate base profiles on OBS (RHEL7.4, RHEL7.5,...)

I ran into this as well. I've logged a bug for it:

I've also written a knowledgebase solution with a workaround:

Thank you, Jamie, for doing a bug report and providing a workaround. Unfortunately I have already installed the latest exiv2-libs, and downgrading it requires a number of other packages also to be downgraded. :( Building a fixed version of exiv2-libs would be easier in this case?

Yes I agree. I only had this one dependency so the workaround works for me, but I understand it might not work for everyone. Let's see what the package maintainer says.

I am hoping Red Hat steps in here, and provides a backwards-compatible exiv2 package to allow older packages to be installed. But in the meantime, my workaround is to build my own version of the package and install it on the side (in a different path, the third-party application in question does define an rpath, so it will fortunately load libraries from these paths). Not an ideal solution, but it can work.

Hi Jamie,

Any update on the bugzilla? Should I open a RfE to get higher priority?

Regards,

Jan Gerrit

The response from Red Hat seems to be that they do not support third-party software (either that, or they didn't understand the issue).

Debian solved this issue decades ago by always renaming the packages when the version number changed, allowing several versions to be installed side-by-side. I am amazed that RHEL gets this wrong.

The solutions suggested on the bug are helpful, thanks for those.

I don't work much in userspace so I don't have anything technical to add sorry. You all know much more than me about ways to solve this.

Whilst exiv2 is not guaranteed any ABI compatibility I'm also surprised we would make a breaking change like this.

I wasn't aware of that document, thanks for providing the link.

My current solution is this:

  1. Take the exiv2-libs package from 7.4 (I am using the CentOS RPM as it is easier to find).
  2. Unpack and repack it into an exiv2-libs-compat package, with only the so files and set up as "Obsoletes: exiv2-libs = 0.23-6"
  3. Install the exiv2-libs-compat package

This seems to work, it fulfills the dependencies for anything that depends on the old exiv2-libs package, without standing in the way of installing the new version.

Thanks, your solution indeed worked for me. Just to expand on step 2 -- in the spec file, replace the "libs" with "libs-compat" and add the Obsolete line to the libs-compat section. Installation of the exiv2-libs-compat package resulted in:

lrwxrwxrwx. 1 root root      18 Apr 28 22:31 libexiv2.so -> libexiv2.so.12.0.0
lrwxrwxrwx. 1 root root      18 Apr 28 22:31 libexiv2.so.12 -> libexiv2.so.12.0.0
-rwxr-xr-x. 1 root root 2408064 Apr 28 17:42 libexiv2.so.12.0.0
lrwxrwxrwx. 1 root root      18 Apr 14 01:34 libexiv2.so.26 -> libexiv2.so.26.0.0
-rwxr-xr-x. 1 root root 3007096 Feb 23 05:14 libexiv2.so.26.0.0