Bug 1568618 - exiv2-libs in RHEL 7.5 not backwards compatible with earlier RHEL 7
Summary: exiv2-libs in RHEL 7.5 not backwards compatible with earlier RHEL 7
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: exiv2
Version: 7.5
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Jan Grulich
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On: 1585668
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-04-17 23:04 UTC by Jamie Bainbridge
Modified: 2018-10-30 10:23 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-10-30 10:23:07 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2018:3140 None None None 2018-10-30 10:23:52 UTC

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


Note You need to log in before you can comment on or make changes to this bug.