Ports that depend on hdf5-18 should switch to hdf5

[mf2k (Frank Schima)]

Ports that depend on hdf5-18 should be updated and tested to work with the newer hdf5 port.

See also #52289.

Port	Maintainer	status
h4h5tools	-
hdfeos5	tenomoto
netcdf	tenomoto	#54177
octave-devel	MarcusCalhoun-Lopez
py-tables	mamoll	Done
ncarg	tenomoto

[mamoll (Mark Moll)]

In 1fa97da43102e3502c9381c05999f5bd8dceee61/macports-ports:

py-tables: update to version 3.4.2, switch from hdf5-18 to hdf5 (see #54101)

[Dave-Allured (Dave Allured)]

Please recall the original reasons for hdf5-18. It is a little hard to tell from the original tickets (ticket:51089 etc), but this alternative port solved two problems:

1. All hdf5 versions starting with 1.10.0 (2016 March 30) could easily generate new hdf5 data files that were backward incompatible with all older, non-updated hdf5 applications. Hdf5-18 prevented this, and wrote only backward compatible files. The correct long term fix is to (a) insert a specific hdf5 compatibility function call into the calling application; then and only then, (b) upgrade to hdf5 1.10.x. For example, here is a discussion and compatibility fix that was applied in Netcdf version 4.4.1 (2016 June 28). The single function call to H5Pset_libver_bounds did the trick:

​https://github.com/Unidata/netcdf-c/issues/250 (2016 April 7)

2. Hdf5 versions 1.10.0 and 1.10.0-patch1 could not access network-mounted files from Macs. I am told this was specifically due to new usage of the system flock function, and shortcomings of NFS version 3 on Macs. This of course would not affect any Mac users that used only local disk files. Hdf5-18 avoided this problem because it never used flock. Hdf5 version 1.10.1 (2017 April 27) appears to fix this, using a special run-time environment variable. IMO the correct upgrade path is to link only with hdf5 1.10.1 or later, and then remind users to use the environment variable when needed. The 1.10.1 update is forthcoming in ticket:54139, which includes details about the environment variable setting.

I recommend holding off on switching hdf5-18 dependencies to hdf5 until either (a) the format compatibility fix is inserted in the calling packages; or (b) there is some kind of consensus that original package developers and users no longer care about generating backward-incompatible hdf5 data files.

Furthermore, because of (2), I recommend waiting for hdf5 1.10.1 (ticket:54139) before switching any more hdf5-18 dependencies back to hdf5.