Bug 1568618
| 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> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 7.5 | CC: | adm.fkt.physik, jangerrit.kootstra, jgrulich, jkoten, klember, lmiksik, peter.krefting, riehecky, toracat, tpelka |
| Target Milestone: | rc | Keywords: | Regression |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2018-10-30 10:23:07 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 1585668 | ||
| Bug Blocks: | |||
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. (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. Could this be solved by a compat-exiv2-libs package, like was common practise with std-libc++ on previous major release of RHEL? (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. (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. 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. 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. 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 |
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