[bug#46830] [PATCH Added hdf5-1.12-parallel-openmpi] * gnu/packages/maths.scm (hdf5-1.12-parallel-openmpi): New package based on HDF5 1.12.0

[zimoun <zimon.toutoune@gmail.com>]

Hi Gerd,

On Wed, 03 Mar 2021 at 08:10, Gerd Heber <gerd.heber@gmail.com> wrote:

> What's your recommendation? Maybe (hdf5-1.6?), hdf5-1.8, hdf-1.10, and hdf5-1.12
> belong into maths.scm, plus the thread-safe builds, but not
> hdf5-parallel-openmpi?

From my understanding, hdf5 at versions 1.8 and 1.10 are used by other
packages.  When those very packages will not use at one of these
versions, I guess the very version will be removed.

hdf5-parallel-openmpi is used by petsc-openmpi for instance.  And this
hdf5 variant is built with version 1.10.  Since there is no package that
requires hdf5-parallel-openmpi at another version than 1.10, I do not
see the point to include it in Guix proper.  Especially when the custom
variant is straightforward to locally create and buildable on a
reasonable amount of time.

However, these words are not totally acceptable. :-) If I take the shoes
of a regular scientist, then they only wants the package at hand and not
necessary RTFM how to do package transformations.

> I tried to build hdf5-1.8.22-parallel-openmpi, but some of the (MPI)
> atomicity tests fail
> with the OpenMPI version used in the current hdf5-parallel-openmpi.

Yes, and we could imagine different versions of openmpi.  And then
compiled with different compiler versions, etc…

> And then there is MPICH...

…and the matrix of combinations is exploding. ;-)


One issue with the channel is to provide substitutes for that channel.
For example, the channel guix-science uses TravisCI to build the package
from GitHub.

<https://github.com/guix-science/guix-science/blob/master/.github/workflows/build.yml>


That’s said, the cons about channels–and so the pros about include the
hdf5 variant in Guix proper–is to keep consistency and detect breakage:
Guix proper updates a package that becomes incompatible with one the
variant living a channel.  All in Guix proper, then Guix CI will detect
it.  Some dependencies in Guix proper and hdf variant in a channel, then
the channel CI probably not since nothing changed (from the channel
side) and so nothing triggered a build.  I do not know.

Well, let stay pragmatic. :-)


> I would also like to see HDFView as a Guix package. We have a Spack
> package, but

It would be really cool!


> I'm sold on the merits of Guix and you are doing fantastic work.
> What's your recommendation, and what can we (The HDF Group) do to help?

Thanks the HDF Group for their interest on Guix.


Where the package definition ends (channel vs Guix proper) is one thing,
maybe a start should to have these hdf5 variant definitions.  Then from
a pragmatic point of view, depending on these definitions (number,
length, etc.), they could ends in (gnu packages maths) or maybe its own
module (gnu packages hdf) or maybe in a channel.   WDYT?


All the best,
simon