exiv2-libs not backwards compatible
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
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
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:
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.
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
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.
