unfortunately, `med-3.3.1` is not compatible with the new version of `hdf5`that was merged today in #13561
```checking H5public.h presence... yes
checking for H5public.h... yes
///usr/include/H5public.h
configure: error:
This HDF5 version 1.10.1 must not be used with med-fichier3.3.1.
The HDF5 library version used by med-fichier3.y.z MUST NOT be > 1.8 and have to be at least 5-1.8.11.
DO NOT TRY TO COMPILE med-fichier3.3.1 version with an HDF5 library which would generate an hdf5 file not compliant with HDF5-1.8.z library.
This would BREAK med-fichier compatibility between files with the same revision number !
```
This breaks the freecad update that was also merged today in #13404 (which included `med` as a new package, so @Chocimier couldn't have known)
thanks.
but... @faulesocke and me were working on it already, coordinated over irc.
We came to the conclusion that all of freecad's dependencies that need hdf5 would have to use the same hdf5 version (and therefore the `1.8`), but that was not tested yet to full extend.
For reference: https://github.com/piraty/void-packages/tree/freecad-med-hdf5-1.8
Also we thought about making sure `hdf5-18`'s bin-files don't conflict with `hdf5`'s. your approach to move them to lib/hdf5-18 seems ok to me for that purpose.
i did some research:
hdf5's configure script has an option `--with-default-api-version=(v16|v18|v110)` (which [debian uses](https://sources.debian.org/src/hdf5/1.10.0-patch1+docs-4/debian/rules/#L101)), which would work for the med incompatibility with hdf5>1.8.
Any thought on setting this to `=v18` in the main template and drop hdf5-18?
I'll leave that to you as I only tried to solve problems without having a deeper insight.
Of course we can drop hdf5-18 as soon as there's a better solution.