I don't think that's what Kaleb was suggesting. Coin2/3/4 packages
contain different SONAMEs:
# dnf repoquery -l Coin4 | grep /usr/lib64
/usr/lib64/libCoin.so.4.0.0
/usr/lib64/libCoin.so.80
# dnf repoquery -l Coin3 | grep /usr/lib64
/usr/lib64/libCoin.so.60
/usr/lib64/libCoin.so.60.1.3
# dnf repoquery -l Coin2 | grep /usr/lib64
/usr/lib64/libCoin.so.40
/usr/lib64/libCoin.so.40.5.0
Now I don't know if it would specifically work for Coin, but for many
C/C++ libraries you can use a single SONAME forever, and versioned
symbols for each symbol that has to change incompatibly. Old binaries
will continue to use the old symbol transparently. New binaries will
use the new symbol. Both will be linked to the same SONAME.
glibc is the most famous/notorious user of this mechanism, but many
other libraries use it too. Uli's documentation is a good place to
start:
https://akkadia.org/drepper/dsohowto.pdf
as well as:
https://gcc.gnu.org/wiki/SymbolVersioning
Is that something that can be easily implemented at the packager level?
Also, in the case of OpenEXR upstream (ASWF) has reorganized the libraries over the last couple of releases[1], merging some and splitting out others creating a real mess. In fact, one of the other ASWF projects, OpenVDB isn't even compatible with OpenEXR 3 and won't be until the next major release.
So is my only real option to create a compat package and migrate all the projects that can't use OpenEXR 3 to it?
For posterity here's my working COPR with the fairly long list of dependencies:
Thanks,
Richard