Bug 1406976

Summary: OpenImageIO not conforming to ABI compatibility by exporting minor in SONAME
Product: [Fedora] Fedora EPEL Reporter: Steven Seed <Steven.Seed>
Component: OpenImageIOAssignee: Richard Shaw <hobbes1069>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: epel7CC: hobbes1069, Steven.Seed
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-12-18 15:31:26 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:

Description Steven Seed 2016-12-22 01:20:16 UTC
Description of problem:

Currently, OpenImageIO is compiled such that the libOpenImageIO library is exporting a SONAME with the minor version. In epel7, the library went from exporting version 1.4 to version 1.5 which is causing dynamic linking issues for code compiled against version 1.4. According to the EPEL policies within a given major release or RHEL, the packages should maintain ABI compatibility otherwise a compat lib should be provided. 

https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#A_little_bit_bigger_minor_version_updates

Version-Release number of selected component (if applicable):
OpenImageIO-1.5.24-3.el7.x86_64

How reproducible:

Always. 

See the SONAME for older 1.4 packages in epel7 like OpenImageIO-1.4.16-1.el7.x86_64:

# objdump -p /usr/lib64/libOpenImageIO.so.1.4 | grep SONAME
  SONAME               libOpenImageIO.so.1.4

And from the latest package OpenImageIO-1.5.24-3.el7.x86_64:


# objdump -p /usr/lib64/libOpenImageIO.so.1.5 | grep SONAME
  SONAME               libOpenImageIO.so.1.5


Actual results:
error: Failed dependencies:
	libOpenImageIO.so.1.4()(64bit) is needed by (installed) ptexutils-1.1.1.3.g4107e62-1.el7.x86_64

Expected results:

It's my understanding that the SONAME exported should be limited to the major version unless there are incompatibles between releases. Therefore, I would expect that the SONAME would be libOpenImageIO.so.1.

Additional info:

Comment 1 Richard Shaw 2016-12-25 14:30:31 UTC
Apologies for the problem. We needed a newer version of pugixml for a new EPEL package[1] and we ran into a bit of a version dependency chain problem trying to get all of the packages built. 

There are no plans to change it again so I hope a simple rebuild fixes your problem. I assume ptexutils is a package you build yourself?

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1347390

Comment 2 Steven Seed 2017-02-02 01:37:50 UTC
Would it be possible to provide a compat package to provide the older libraries so we can still upgrade to the newest packages without having to rebuild our software?

Comment 3 Richard Shaw 2017-02-02 16:43:15 UTC
Since that would require completion of a Review Request and mangling of the install so both packages could potentially be installed at the same time that's a fair bit of work.

Does ptexutils not build against the newer version?

Comment 4 Steven Seed 2017-02-02 18:13:36 UTC
I'm not sure it builds. My guess is it will build without a problem. The issue is we are in a maintenance mode with the software currently and don't want to make any changes that my introduce new bugs or require testing for at least another 6 months, so there is resistance by our company to do that.  

Even if we do rebuild now, what will happen next time? We are mostly trying to highlight the problem so that it doesn't happen in the future.

Comment 5 Steven Seed 2017-02-02 18:14:13 UTC
I'm not sure it builds. My guess is it will build without a problem. The issue is we are in a maintenance mode with the software currently and don't want to make any changes that my introduce new bugs or require testing for at least another 6 months, so there is resistance by our company to do that.  

Even if we do rebuild now, what will happen next time? We are mostly trying to highlight the problem so that it doesn't happen in the future.

Comment 6 Richard Shaw 2017-02-21 15:41:09 UTC
Bah... Trying to create a compat package and now I'm having build errors that I never had when 1.4.x was "current".

Comment 7 Richard Shaw 2017-02-21 16:36:49 UTC
Ok, I can get it to build now but instead of doing a compat package I plan on bumping the Epoch and downgrading to 1.4.16. I just emailed the owners of blender to make sure they don't object.

Comment 8 Steven Seed 2017-10-16 21:16:23 UTC
Has there been any progress with this? From what I can see, the OpenImageIO packaging hasn't changed.

Comment 9 Richard Shaw 2017-10-22 14:13:42 UTC
I bumped the Epoch and tried to do a build but the build system still refused saying it had already been built. Admittedly I got really frustrated and gave up for a while.

Comment 10 Steven Seed 2017-10-23 18:36:54 UTC
We have started to move ahead with rebuilding our software that depends on OpenImageIO to use the newer version.

Comment 11 Richard Shaw 2017-10-23 19:38:35 UTC
That might be best overall, sorry it was so much trouble.

Comment 12 Richard Shaw 2017-12-18 13:37:32 UTC
Any update here? Were you able to validate using the newer OpenImageIO?

Comment 13 Steven Seed 2017-12-18 15:10:51 UTC
Yes. Once recompiled against the newer version our software worked properly.

Comment 14 Richard Shaw 2017-12-18 15:31:26 UTC
Ok, good. Sorry for the inconvenience.