[Pkg-octave-devel] liboctave-dev insists on serial version of the hdf5 library

[Sébastien Villemot]

Rafael Laboissiere <rafael at laboissiere.net> writes:

> * Thomas Weber <tweber at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-octave-devel/attachments/20120814/c4315e83/attachment.pgp>