On 07/10/16 16:30, Alastair McKinstry wrote: > Are we going to try and do the HDF5 transition before the freeze, which > is the end of the month for transitions?
I'll leave that to Gilles who has done a marvellous job on hdf5, although I'm not happy with the Debian specific changes to HDF5 we need to deal with (non-standard include & library paths mostly). Regarding HDF5 1.10, the changes in NetCDF 4.4.1 are required to not cause backward compatibility issues as discussed previously: https://lists.debian.org/debian-gis/2016/04/msg00042.html Since netcdf 4.4.1 is in testing/unstable for some time, that's no longer a blocker for the hdf5 transition. > I'm testing out the last of my changes for co-installable netcdf which I > hope to have ready by the beginning of next week. It would be worth > thinking about doing both. I'm aware of the outdated dev-coinstallable branch in the netcdf repository, and no offence to your effort, but I don't like what I see there. The symbols version script will be a pain to maintain as our experience with gdal has shown for example. I'm still very much against patching the netcdf source to make it build with HDF5 serial and its MPI variants. That needs to be solved upstream. I don't want to require changes to reverse dependencies to select a Debian specific netcdf variant as we do for hdf5. The situation we want to create in Debian should be something supported out of the box by upstream. Has there been any discussion with NetCDF (and HDF5) upstream about this? Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
