Let hdf5-18 maintainer revision bump all its dependents

[florian@…]

Wouldn't it make sense if the maintainer of hdf5-18 revision bumps all of its dependents after updating to a new version? This would greatly ease the workflow and would not cause any delays. Right now, users are wondering why netcdf and gdal do not work anymore.

[eborisch (Eric A. Borisch)]

Fixed cc addresses.

For the record, I'm find with py-h5py being revbumped by the hdf5-18 maintainer, but I'm also happy to do it myself -- it just may take a day or two.

[ryandesign (Ryan Carsten Schmidt)]

If someone updates a port to a new version that has a new library version so that all dependents must be rebuilt (did r92994 do that?) then yes, it would be the responsibility of that someone to revbump all those dependents so that they are not broken. There is no need to involve the maintainers, if any, of those ports that would be broken by not doing so.

[mamoll (Mark Moll)]

Done in r93321 and r93322.

[florian@…]

Thanks for the clarification and thanks for revbump. Btw, is there a possibility to automate this tedious task? Unfortunately the list of packages that depend on hdf5-18 and that might potentially break by a new library version is quite long:

H5Part
alps
field3d
flann
gdal
gnudatalanguage
h4h5tools
h5utils
hdfeos5
nco
netcdf
octave
octave-devel
p5-pdl
petsc
py-h5py
py-tables
shogun
silo
swarm
vapor
vigra
wgrib2

AFAICT all of these would have to be revbumped after an update.

[eborisch (Eric A. Borisch)]

r93321 was more than a rev bump; it added some new configure flags. Intentional?

[mamoll (Mark Moll)]

No, accidental. Sorry. Removed in r93333. (I suspect I had done this to get gdal working with hdf5-18+openmpi.)

[tenomoto (Takeshi Enomoto)]

Replying to florian@…:

Btw, is there a possibility to automate this tedious task?

The revision field has dual task. Let it represent the true revision of Portfile and add another filed for the library update. How about forcing port -R when the library version in Portfile (say, library_version) is incremented?

[florian@…]

Replying to takeshi@…:

The revision field has dual task. Let it represent the true revision of Portfile and add another filed for the library update. How about forcing port -R when the library version in Portfile (say, library_version) is incremented?

Do you mean this as a feature request to the port command? Say, the Portfile of hdf5-18 has an entry library_version and whenever this is incremented, all dependents will be rebuild as in 'port -R upgrade hdf5-18'? Indeed then the maintainer of the library does not have to bother about revbumping all dependents. Good idea.

But this doesn't answer my other question: As a maintainer how do I (1) find out which are the dependents of hdf5-18 and (2) how would I bulk increment the revision number in each of the dependents Portfiles. For (1) it might be tempting to call:

port search --line --depends_lib hdf5-18

but this misses out all depends_lib-append in variants. Unfortunately neither of these constructs work:

port search --line --depends_lib-append hdf5-18
port search --line --depends_lib hdf5-18 +hdf5

[tenomoto (Takeshi Enomoto)]

I also feel that the bulk revision update is tedious and I want to make is automatic. What I suggest was:

sudo port upgrade

fire up

sudo port -R upgrade

when library_version is incremented. The increment of library_version is all the maintainer has to do. I agree that what you suggest is handy to check the dependencies but that is not needed if everything is automatic. Isn't automation what the package management system is for? I'm not sure if I am asking for something difficult or not and I'm not sure if this would be a duplicate. So I hesitate to file a ticket.

[florian@…]

Then we basically agree here. Actually the new rev-upgrade feature goes into the same direction. I don't know if there are requests for a similar feature but I did not check thoroughly yet.

[eborisch (Eric A. Borisch)]

Rev-upgrade does do some of the same, but hdf5-18 is a special case; the libraries that the executable wants to link against still exist, but HDF5 takes the approach of throwing an error (along with information on how to set an environment variable to proceed anyway) if the library isn't the exact version the executable was compiled with.

This type of run-time "issue" won't be caught by rev-upgrade, as the required .dylib files are there (which is what rev-upgrade checks for, if I recall)...

[florian@…]

Like you said rev-upgrade seems to check only for renames. I wonder whether the exact procedure is documented somewhere. The easiest way to ensure that rev-upgrade correctly picks up the hdf5 upgrade is to rename the library with each new library version, e.g., from libhdf5.7.dylib to libhdf5.8.dylib. I would consider the fact that the version in the filename of the lib does not reflect its compatibility version a bug although I believe this is intended by the hdf5 guys in order to print the compatibility warning.

It would be great if rev-upgrade would pick up a change in the "compatibility version". But then we have to file a bug against hdf5 that they increase the compatibility version for each release that would break the API. Right now they increment only the "current version" although they claim the versions are incompatible:

$ port activate hdf5-18 @1.8.8_0+universal
$ otool -L /opt/local/lib/libhdf5.7.dylib
/opt/local/lib/libhdf5.7.dylib:
        /opt/local/lib/libhdf5.7.dylib (compatibility version 8.0.0, current version 8.2.0)
        /opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.7)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11)

$ port activate hdf5-18 @1.8.9_0+universal
$ otool -L /opt/local/lib/libhdf5.7.dylib
/opt/local/lib/libhdf5.7.dylib:
        /opt/local/lib/libhdf5.7.dylib (compatibility version 8.0.0, current version 8.3.0)
        /opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.7)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11)

It seems there are several possibilities but to me the most robust right now looks like changing the install name of the hdf5 library each time it is updated so that rev-upgrade kicks in.