Support for OpenEXR-3 / Imath?

[waebbl]

Hi,

is there a chance, the library will support OpenEXR-3 / Imath in the foreseeable future?

The package is one of very few in Gentoo Linux, which still needs the old OpenEXR-2.5 / IlmBase packages. As a maintainer of these packages, I'm currently checking removal of these versions from the repository.

TIA

[lgritz]

Does anything else in Gentoo use CTL as a dependency? It's a bit of a specialized thing, I'm a little curious how it got swept into a major Linux distro in the first place.

Note: there doesn't appear to have been a tagged release of CTL since 2014?

[waebbl]

No package in Gentoo depends on CTL. It has been in Gentoo for many years and got moved from CVS when we migrated to Git back in 2015. Eventually someone adapted it from BDS ports, on which the Gentoo package manager is based off, but it's origin is currently unknown to me. It's on a few other major distros as well[1][2].

As long as it builds, no major bugs are reported and the package is still maintained, it's age isn't very important.

[1] https://repology.org/project/ctl/versions
[2] https://repology.org/project/ampasctl/versions

[michaeldsmith]

Hi - I volunteered to be the maintainer of CTL earlier this year. So far I've focused on fixing the bugs that impacted my own usage of CTL and ctlrender in my work. I also added CI workflows including valgrind and addressanitizer, and I fixed the bugs that were found by those tools.

@waebbl we could work on supporting OpenEXR-3/Imath if you think its important, is your goal to completely remove OpenEXR 2.5.x ? It appears that the OpenEXR 2.5.x branch is still under active maintenance (last release was March 2022).

@lgritz would it help if we made a new 1.5.3 tag release of CTL? Do you think it would need to include anything more than the bug fixes I've already committed to master branch?

[lgritz]

I think we should take a hard look at whether anybody actually needs the Gentoo pre-built CTL package. If not, they should drop it from their distro in an effort to clear the way for them to upgrade to OpenEXR/Imath 3.1 for the rest of their packages that need OpenEXR/Imath.

OpenEXR 2.5 is definitely past its support window. In March 2022 we tagged a release that contained two very minor build-related fixes, probably as a favor for somebody who specifically requested it. The previous 2.5 patch was almost a year earlier and only contained fixes to critical security bugs. Currently, we're working toward 3.2 and I think I can speak for the OpenEXR dev team and say that 2.x should not expect any further updates and it's our position that everybody should be moving to 3.x ASAP.

[waebbl]

@michaeldsmith Sadly I can not say how important the package is. We don't have reliable numbers on how often a package is installed by users. It doesn't hurt to keep IlmBase / OpenEXR-2.5 around for a while longer, as long as the packages build and security issues are getting fixed. If there's a decision to not upgrade CTL to use Imath / OpenEXR-3, we might eventually have to drop CTL from the repo at some point, if IlmBase / OpenEXR-2 don't get any more security updates.

@lgritz We don't have pre-built CTL packages. Gentoo is a source-base rolling release distro. The package also doesn't block upgrades for packages using OpenEXR-3 / Imath. We currently have packages for v3.1 and v2.5, but they can't be installed at the same time. So if someone wants to install CTL it will in fact block installing the many packages which already use OpenEXR-3 / Imath, including packages like blender, krita, osl or oiio. At the beginning of v3 we had a way to install both, v3 and v2.x in parallel, but this was very fragile and we needed to manually change a few things in the build system for either v3 or v2.x, so we dropped this.

A list of packages depending on IlmBase can be seen at [1]. [B] means blocking, i.e. the package can't be installed at the same time with IlmBase. I checked this list and all packages, but CTL also have newer version in the repo which use OpenEXR-3 / Imath, so all of these could be dropped. One other package YafaRay is using OpenEXR-2, but we can disable it by dropping optional support for EXR format until they come up with a newer release.

[1] https://qa-reports.gentoo.org/output/genrdeps/rindex/media-libs/ilmbase

[michaeldsmith]

@waebbl I have merged pull request #103 into CTL master branch which enables building CTL and ctlrender without the OpenEXR v2 library. The IlmBase library is still required. Does that help address your original issue and question? It seems IlmBase is still available from modern ubuntu package mangers. I'm not sure if Gentoo will continue to support IlmBase. Also, I don't know if its possible to keep a legacy IlmBase v2 and a newer OpenEXR v3 on the same system.

@lgritz do you have any interest in submitting a pull request to CTL that would update it to use the latest OpenEXR v3 libraries instead of IlmBase ?

[waebbl]

@michaeldsmith Thanks for your effort in updating the library. It will not help with my original issue though. We still have OpenEXR-2.5 and IlmBase packages in Gentoo, but they are both definitely bound for EOL. There's no set date for this however, and if there's effort to update to OpenEXR-3 I think we can keep them some more time. On Gentoo it's currently not possible to have OpenEXR-3 and IlmBase-2 packages installed on the same system at the same time. AFAIR this will lead to file collisions for some header files which are in both, OpenEXR-3 and IlmBase, like for example Iex.h.
If I read your patch in #103 correctly, OpenEXR is only needed for one test suite. This gives me the opportunity to restrict the specific test for the test suite, and build with only IlmBase support. I'm trying to use your patch in my PR gentoo/gentoo#28278 and remove the dependency on OpenEXR.

[lgritz]

Keeping an old version of the "IlmBase" portions of OpenEXR 2.5 in an otherwise Imath-3.x world will cause all sorts of subtle problems with conflicting header files and symbols. Plus, those 2.x versions no longer get updates, even for critical security bugs, which puts any project that uses them in danger of having vulnerabilities discovered that could prevent them from being used in commercial products or being included in OS distributions. CTL really needs to be converted to a modern, maintained version of Imath.

I'm not a good candidate for writing a PR for CTL, both because my time is already wildly oversubscribed, and also I have never built or used CTL and am not really familiar with its codebase -- I'd be starting from scratch. Surely there is somebody better suited than me to do this work.

I did write a porting guide with the specific goal of making it so I wouldn't have to do the conversion myself in other code bases. That was actually done for the 3.0 release when we thought people would need to simultaneously support OpenEXR/Imath 2.x and 3.x for some time. Now that it's a few years later, if you can take the leap and require 3.0 as a minimum, it's even simpler because you won't need all the #if nonsense that handles either version.