Rafael Laboissiere <rafael@laboissiere.net> writes: > * Thomas Weber <tweber@debian.org> [2012-08-13 18:41]: > >> My knowledge of hdf is pretty outdated, but afaik the serial and mpi >> versions are not interchangeable: the serial version can do things the >> parallel version cannot.[1] > > I have not looked in detail into this issue, but both libhdf5-openmpi-7 > and libhdf5-mpich2-7 (the parallel versions) provide libhdf5-7 (which is > the serial version). Unless I am getting it wrong, this kind of > relationship suggest that the packages are indeed interchangeable I have just asked Sylvestre about this, and the situation is a bit more complicated. The 3 versions of HDF5 are ABI-incompatible. But still they expose a common subset of interface, which is the reason of the Provides. In a perfect world the Provides should not exist, but the HDF5 maintainers added it as a convenience feature to minimize the number of co-installability issues. In practice tools like Scilab and Octave only use the subset of features which is common to the 3 versions, so it is reasonable to consider them as if they were ABI-compatible for our purpose. The ideal solution would be to have these libraries using different names so that they can be co-installed while considered as ABI-incompatible, but upstream is slow to react. >> You might want to ask Sylvestre about it, as he said that he needed the >> serial version for Scilab. I found the ability to have both Octave and >> Scilab on a system more important than an octave-forge package. > > Right now, all packages that depend on libhdf5-openmpi-7 are not > co-installable with octave: You probably meant liboctave-dev. As already mentionned, Octave (and Scilab) are coinstallable with libhdf5-openmpi-7. >> One of the things that might be a blocker: depending on the installed >> flavor of hdf5 on a buildd, Octave will link against a different >> library. This might mean that we run into library transitions for Octave >> without even knowing it (like, build #1 is linked against the serial >> version and the next build #2 is linked against the parallel version). > > My knowledge of the buildd is quite sparse, but I would guess that this > will not happen if the solution proposed by Sébastien is adopted, because > in the alternation of the liboctave-dev dependencies > libhdf5-dev|libhdf5-openmpi-dev|libhdf5-mpich2-dev, the buildds will > always pick the first one. Am I wrong? I think you are right, expect for packages like octave-msh which will be built against libhdf5-openmpi-dev because of gmsh (but this is what we want). Implementing this change should therefore not change the way existing Octave packages are built, while allowing building currently unbuildable packages like octave-msh. To summarize, my feeling is that allowing the co-instability of liboctave-dev with all 3 versions of HDF5 brings clear advantages (less co-instability issues) and at the same time it won't break anything for people using the serial HDF5 version. People wanting to use the parallel versions will be allowed to do so; in the worst case they could be hit by the partial ABI-incompatibility, but it is still better than the current situation where we just forbid them from using the parallel version. -- .''`. Sébastien Villemot : :' : Debian Maintainer `. `' http://www.dynare.org/sebastien `- GPG Key: 4096R/381A7594
Attachment:
pgpzIoZcRd5Se.pgp
Description: PGP signature