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