|Summary:||exiv2-libs in RHEL 7.5 not backwards compatible with earlier RHEL 7|
|Product:||Red Hat Enterprise Linux 7||Reporter:||Jamie Bainbridge <jbainbri>|
|Component:||exiv2||Assignee:||Jan Grulich <jgrulich>|
|Status:||CLOSED ERRATA||QA Contact:||Desktop QE <desktop-qa-list>|
|Version:||7.5||CC:||adm.fkt.physik, jangerrit.kootstra, jgrulich, jkoten, klember, lmiksik, peter.krefting, riehecky, toracat, tpelka|
|Fixed In Version:||Doc Type:||If docs needed, set a value|
|Doc Text:||Story Points:||---|
|Last Closed:||2018-10-30 10:23:07 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:||1585668|
Description Jamie Bainbridge 2018-04-17 23:04:27 UTC
Description of problem: If you have a package which depends on the older exiv2-libs-0.23-6.el7 providing libexiv2.so.12, then you update to RHEL 7.5, the latest exiv2-libs-0.26-3.el7 only provides libexiv2.so.26 As a result, the exiv2-libs package cannot be updated as the update breaks dependencies for the package which needs the older version. Version-Release number of selected component (if applicable): exiv2-libs-0.26-3.el7 How reproducible: Always Steps to Reproduce: 1. Install RHEL 7.4 2. Install a package which depends on libexiv2.so.12 such as gnome-classic-session from the RHEL Server channel, or geeqie from nux-dextop repo 3. yum update to RHEL 7.5 Actual results: Cannot update due to exiv2-libs version mismatch: --> 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 Expected results: Update works fine. Additional info: This is discussed on the customer portal at: https://access.redhat.com/discussions/3414821
Comment 2 Jan Grulich 2018-04-18 06:18:25 UTC
Incompatibility with 3rd party repositories is not problem on our side, apps in 3rd party repositories will need to rebuild all applications depending on exiv2. From the log you sent it doesn't seem that gnome-classic-session fails because of exiv2.
Comment 3 Peter Krefting 2018-04-18 06:26:32 UTC
(In reply to Jan Grulich from comment #2) > Incompatibility with 3rd party repositories is not problem on our side, apps > in 3rd party repositories will need to rebuild all applications depending on > exiv2. The problem with third-party apps is that this change means that 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. Incompatibly changing a library soname in a minor release is prone to break compatibility, and should be avoided.
Comment 4 ir. Jan Gerrit Kootstra 2018-04-19 09:17:45 UTC
Could this be solved by a compat-exiv2-libs package, like was common practise with std-libc++ on previous major release of RHEL?
Comment 5 ir. Jan Gerrit Kootstra 2018-04-19 09:20:44 UTC
(In reply to ir. Jan Gerrit Kootstra from comment #4) > Could this be solved by a compat-exiv2-libs package, like was common > practise with std-libc++ on previous major release of RHEL? The original poster of https://access.redhat.com/discussions/3414821 states his third party package can be reconfigured to point to a path where the compatibility version of exiv2-libs can be found.
Comment 6 Peter Krefting 2018-04-19 11:48:26 UTC
(In reply to ir. Jan Gerrit Kootstra from comment #5) > The original poster of https://access.redhat.com/discussions/3414821 states > his third party package can be reconfigured to point to a path where the > compatibility version of exiv2-libs can be found. Yes, for this particular package it works (but I still need to build my own package for the old exiv2 library). Including a compatibility package in the distribution would save me the trouble, and fix it for anyone else seeing it. As mentioned in the discussion thread, I am not the only one to have an issue with this.
Comment 7 Peter Krefting 2018-04-20 09:06:16 UTC
My current solution is this: 1. Take the exiv2-libs package from 7.4. 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.
Comment 9 Kalev Lember 2018-05-29 12:34:15 UTC
Here's my take on this: 1) There's little point in packaging anything beyond the shared libraries. This is what's needed for the binary compatibility; having anything else just makes things more complicated. 2) I'd name the package "compat-exiv2-023", or "compat-exiv2-0.23", to follow the same name pattern we've used in other places 3) No need for Obsoletes as suggested in comment 7: if a third party rpm has a dependency on the old ABI version, then the compat package is pulled in automatically. 4) I'd add a "Conflicts: exiv2-libs < 0.26" so that RPM knows that it can't install RHEL 7.3 exiv2-libs and the new compat-exiv2-023 together (file conflicts). Look at how we did it with https://src.fedoraproject.org/rpms/compat-tracker1/blob/59acd19b1d1c22be2618bab0cf8687a3a01ba2cb/f/compat-tracker1.spec for example, it's really super simple packaging, dropping everything else besides the shared library with rm and only packaging up "*.so.*" and the license file.
Comment 16 errata-xmlrpc 2018-10-30 10:23:07 UTC
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2018:3140