openexr: update to 3.4.2 from 3.2.4

[JGoldstone]

Description

Update to openexr 3.4.2 release

Type(s)

• bugfix
• [X ] enhancement
• security fix

Tested on

macOS 15.7.1 24G231 arm64
Xcode 26.0.1 17A400

Verification

Have you

• followed our Commit Message Guidelines?
• squashed and minimized your commits?
• checked that there aren't other open pull requests for the same change?
• referenced existing tickets on Trac with full URL in commit message?
• checked your Portfile with port lint?
• tried existing tests with sudo port test?
• tried a full install with sudo port -vst install?
• tested basic functionality of all binary files?
• checked that the Portfile's most important variants haven't been broken?

[macportsbot]

Notifying maintainers:
@mascguy for port openexr.
@MarcusCalhoun-Lopez for port openexr.

[barracuda156]

@JGoldstone AFAIK updating to a newer minor version will need revbumping dependents. I had to do this when I moved from 3.2.x to 3.3.x: macos-powerpc/powerpc-ports@659621e (these may not be all dependents currently).

[JGoldstone]

@barracuda156 I have two questions, one regarding whether the revision fields need bumping in dependent ports and the other regarding how, if that's needed, to find all the dependent ports.

The 'whether' question: the documentation for the revision keyword in the MacPorts Guide describes revision as

An optional integer (the default is 0) that is incremented when a port is updated independently of the version of the software. ...

But the version of the software is being updated here, that's the whole point. Am I missing something?

If I am missing something then there's the 'how' question: how do I determine the set of ports S that depend on port P? If I use port echo dependentof: openexr, for example, the output includes ports that I have installed (opencolorio, opencv4) but not dependent ports that I don't have installed (e.g. openvdb). The information is clearly there, in the set of 40,000+ Portfiles in macports-ports, but (a) do I need it and (b) if so how do I get it?

[barracuda156]

Revision of a dependent should be increased when linking breaks due to dylib version change. For example, one of libjxl port binaries:

% otool -L /opt/local/bin/benchmark_xl
/opt/local/bin/benchmark_xl:
	/opt/local/lib/libjxl_threads.0.11.dylib (compatibility version 0.11.0, current version 0.11.1)
	/opt/local/lib/libjxl.0.11.dylib (compatibility version 0.11.0, current version 0.11.1)
	/opt/local/lib/giflib5/lib/libgif.7.dylib (compatibility version 0.0.0, current version 7.2.0)
	/opt/local/lib/libjpeg.8.dylib (compatibility version 8.0.0, current version 8.3.2)
	/opt/local/lib/libpng16.16.dylib (compatibility version 65.0.0, current version 65.0.0)
	/opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.3.1)
	/opt/local/lib/libOpenEXR-3_3.32.dylib (compatibility version 32.0.0, current version 32.3.3)
	/opt/local/lib/libOpenEXRUtil-3_3.32.dylib (compatibility version 32.0.0, current version 32.3.3)
	/opt/local/lib/libOpenEXRCore-3_3.32.dylib (compatibility version 32.0.0, current version 32.3.3)
	/opt/local/lib/libIex-3_3.32.dylib (compatibility version 32.0.0, current version 32.3.3)
	/opt/local/lib/libIlmThread-3_3.32.dylib (compatibility version 32.0.0, current version 32.3.3)
	/opt/local/lib/libImath-3_1.29.dylib (compatibility version 29.0.0, current version 29.11.0)
	/opt/local/lib/libjxl_cms.0.11.dylib (compatibility version 0.11.0, current version 0.11.1)
	/opt/local/lib/libbrotlidec.1.dylib (compatibility version 1.0.0, current version 1.1.0)
	/opt/local/lib/libbrotlicommon.1.dylib (compatibility version 1.0.0, current version 1.1.0)
	/opt/local/lib/libbrotlienc.1.dylib (compatibility version 1.0.0, current version 1.1.0)
	/opt/local/lib/libhwy.1.dylib (compatibility version 1.0.0, current version 1.2.0)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 902.1.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.100.1)

As long as openexr provides libOpenEXR-3_3.32.dylib, all is good. Once dylib version is changes, libjxl port will be broken.

You can use grep or a similar tool to find ports which have openexr among dependencies. I do not know how to check in bulk which of those use full dylib versioning for linking and which may just link to libOpenEXR.dylib (if any).

[JGoldstone]

I am genuinely surprised there is nothing built into the port command for such a common use case.

There are many libraries or applications that include both Imath and OpenEXR. To avoid non-monotonic changes to the Revision value for ports of those libraries or applications, I suggest we put this PR on a side burner for a bit until the Imath dependencies can be sorted out and that PR merged. Does that sound reasonable to you?

MacPorts support for the ASWF stack has gotten a bit stale; in addition to this (OpenEXR), and Imath, I foresee changes to Alembic, OpenVDB, OpenColorIO and OpenImageIO happening in that order. If these are iterated serially, then the OpenImageIO port is going to show up with increasing Revision numbers in five PRs. But better that, I think, than bundling multiple ASWF ports into one PR.

[JGoldstone]

So if we compare libImath with libjpeg, for example, we have:

 1022 % ls -l | grep -i imath
-rwxr-xr-x    1 root      wheel    339672 Oct 23 08:14 libImath-3_2.30.3.2.2.dylib
lrwxr-xr-x    1 root      wheel        27 Oct 23 08:14 libImath-3_2.30.dylib -> libImath-3_2.30.3.2.2.dylib
lrwxr-xr-x    1 root      wheel        21 Oct 23 08:14 libImath-3_2.dylib -> libImath-3_2.30.dylib
lrwxr-xr-x    1 root      wheel        18 Oct 23 08:14 libImath.dylib -> libImath-3_2.dylib

and

 1023 % ls -l | grep -i jpeg
-rwxr-xr-x    1 root      wheel    471616 Sep  6 12:41 libjpeg.8.3.2.dylib
lrwxr-xr-x    1 root      wheel        19 Sep  6 12:41 libjpeg.8.dylib -> libjpeg.8.3.2.dylib
-rw-r--r--    1 root      wheel    588616 Sep  6 12:41 libjpeg.a
lrwxr-xr-x    1 root      wheel        15 Sep  6 12:41 libjpeg.dylib -> libjpeg.8.dylib

In the otool -L output above what's stored for libjpeg is
/opt/local/lib/libjpeg.8.dylib (compatibility version 8.0.0, current version 8.3.2)

Would things be better if Imath also created a link that looked like this?
lrwxr-xr-x 1 root wheel 18 Oct 23 08:14 libImath.30.dylib -> libImath-3_2.dylib

Of course the actual install name of the library would have to be match this as well, so that linking against it wrote that name into the linking executable or library.

Does that make sense to you?

Finally a question: is it normally the task of a MacPorts contributor that updates a port of a library, such that the library API changes and the compatibility version goes up, to find all the dependent ports in the ports tree, and bump their revisions?

[barracuda156]

@JGoldstone It is probably done on purpose (at least in a case of a big project like openexr) that dylib id uses version that way, since presumably API may have breaking changes between minor versions. If so, we would only make it worse by tweaking installation to use a plain openexr.dylib string. Openexr upstream is responsive, AFAIK, this question can be asked there.

You (or anyone) is not expected to check every dependent for every update of every port, that will be infeasible. However for ports with multiple dependents it makes sense to do some testing, otherwise a lot of ports can be broken by an update (that still happens in practice, unfortunately, exactly because often no testing is done at all). I usually check commit history in such cases, since such breakages won’t go unnoticed, and if an update was done with mass revbump before, it is probably needed now as well.
In this particular case you may just revbump dependents and wait for CI to complete, IMO. This is minimal work for a few minutes, and it is better than leaving all or some dependents broken. But I don’t think you have to confirm that revbump is required for every dependent individually.

[JGoldstone]

I'm on the OpenEXR TSC but as almost everyone else is a pure linux user, at least as far as work goes, I'm the only one who really cares about this. I wasn't proposing to set the install name to a bare openexr.dylib string, that would be a disaster; I was proposing to have openexr.<compatibility version>.dylib as the install name, and noted that was what libjpeg was doing.

Because Imath is in the same boat, and OpenEXR depends on Imath, I'm going to finish #29731 first by adding dependent revision bumps to that PR, then let the dust settle, then do the dependent version bump for this PR and let the dust settle, then keep going with the other ASWF components.

This bumping up the revision numbers of dependents, though, still isn't enough to deal with just how delicately incompatible the Imath/OpenEXR mess is. There are some discussions on long-term solutions that would probably require a major version number bump to the 4.x series. But to get a sense of how bad things are, look at https://openexr.com/en/latest/install.html#build-from-source (in particular the section "OpenEXR/Imath Version Compatibility").

[JGoldstone]

@barracuda156 if you have a chance to look at the Imath revamp commit and tell me whether that's what you thought should happen, I'd appreciate it. Note that for a couple of them (the OpenCV ones for sure) the revision numbers appeared in two places, one for the library and one for the Python bindings; but since it's an outstanding issue IIRC that the Python bindings actually don't get built, I didn't revamp those. LMK if I should do those as well.

If it's approved, would someone else be doing the squashing of the commit? I actually am so new at this I don't know how.