Adrian Schröter writes:
On Freitag, 19. Januar 2018, 15:26:02 CET wrote Adrian Schröter:
On Freitag, 19. Januar 2018, 15:16:04 CET wrote Egbert Eich:
med-tools are failing now, because they explicit warn about 1.10 due to on disk incompabilities:
[ 206s] This HDF5 version 1.10.1 must not be used with med-fichier3.2.1. [ 206s] 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. [ 206s] DO NOT TRY TO COMPILE med-fichier3.2.1 version with an HDF5 library which would generate an hdf5 file not compliant with HDF5-1.8.z library. [ 206s] This would BREAK med-fichier compatibility between files with the same revision number !
I can of course patch this but it feels a bit bad if they warn that way...
Will try to find out more about it and leave the build broken atm, so the published repository should not build anything what breaks the files a user is storing to disk...
Let's include the version number into the package name of hdf5.1.8 then. This is what we do for HPC packages all the time. If hdf5 1.8 is considered to be some sort of reference base, we could flag it as such and build packages that require a stable reference base on it. This still doesn't give you files which you can exchange with your friends who are using tools from other distros with different 'reference bases' ... In theory, we could use environment modules to make other packages available only for the hdf5 version they have been built for. Our packaging macros for HPC are currently not set up for this. It could be done but would make things even more ugly. I at least hope these packages do not use the MPI version of hdf5.
Generally, in an HPC environment, these issues don't arise as people stick to the version they have started their project with. This is why for a distro (like Leap) we keep the old versions around.