SO version change in 2.2.1

[gdsotirov]

As far as I understand 2.2.1 is a maintenance (patch) release addressing only the CVE security issues. However, surprisingly (for me) the SO versions have changed from 22 to 23, which breaks packages depending on OpenEXR (e.g. transcode, VLC and OpenCV). Are there any ABI/API changes in the new release for which this change of the SO version was necessary or there is another reason?

# ls -l /usr/lib/libIlm*.so.*
lrwxrwxrwx 1 root root      23 Dec  6 20:02 /usr/lib/libIlmImf-2_2.so.23 -> libIlmImf-2_2.so.23.0.0
-rwxr-xr-x 1 root root 2995496 Dec  6 20:01 /usr/lib/libIlmImf-2_2.so.23.0.0
lrwxrwxrwx 1 root root      27 Dec  6 20:02 /usr/lib/libIlmImfUtil-2_2.so.23 -> libIlmImfUtil-2_2.so.23.0.0
-rwxr-xr-x 1 root root  149796 Dec  6 20:01 /usr/lib/libIlmImfUtil-2_2.so.23.0.0
lrwxrwxrwx 1 root root      26 Dec  6 19:56 /usr/lib/libIlmThread-2_2.so.23 -> libIlmThread-2_2.so.23.0.0
-rwxr-xr-x 1 root root   22096 Dec  6 19:56 /usr/lib/libIlmThread-2_2.so.23.0.0

P.S. The SO version for IlmBase has also changed from 12 to 23.

[malaterre]

@mfvescovi Looks like we will need to bump the ABI also in Debian. Upstream took a very (too much?) conservative approach in releasing 2.2.1. If we keep a local patch to preserve 12 in Debian, this would mean custom compiled binary will not work within Debian.

[FrancoisLFL]

Thanks for flagging this! We've reached out to the community to get general feedback on how to address this (see message subject "Request for feedback: OpenEXR v2.2.1 .so version changes" on openexr-devel). We'll update this Issue with the outcome of that.

[dracwyrm]

Accoring to commit e69de40 it seems like the devs just wanted the so version to line up across all products when before they were different.

[gdsotirov]

Yes @dracwyrm, that's clear even from the log message, but devs shold have estimated that bumping major so version, breaks the programs alraedy linking to the library, so they should either release a new major version (e.g. 3.0.0 to indicate the change) or not do it in a meintenance release that only contains security fixes.

[dracwyrm]

@gdsotirov I had the same thought about so version change. I can understand why they wanted to make them all the same, but a point release is not where it's done. The only other thing that I can think of is to ensure the new version with security fixes is linked to correctly. Some software may be statically linked or dynamically.

This was not so much an issue on Gentoo where everything on the users computer is recompiled, but I can see the issue on binary based distros having to repackage all programs depending on IlmBase/OpenEXR.

[cary-ilm]

Looking into the backlog of open OpenEXR issues, this was never closed. Looks like the so version didn't in fact need to bump with the 2.2.1 release. Closing for now, with the advisory that maintenance releases in the future won't repeat the mistake.

[gdsotirov]

@cary-ilm Thanks for the understanding.