Subject: [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

From: Ludovic Courtès <[email-masked]>
Date: Mon, 08 Mar 2021 15:01:42 +0100

Hi Gerd,

Gerd Heber <[email-masked]> skribis:

> Ludovic, how are you? Thanks for taking the time to reply. This
> conversation makes
> me wonder what the Guix model for packages such as HDF5 might be.
> On the one hand, there should be defaults for typical, i.e., non-HPC users, and
> they probably belong into gnu/packages/maths.scm. Once you add MPI to the
> mix, things get a little more complicated, and channels, such as
> Guix-HPC might be
> the better place. (?) Should we run our own channel?

As you write, the goal for packages in Guix proper should be to have
“good defaults”, and possibly useful variants, as is currently the case
with HDF5.

We won’t keep all versions and variants in Guix proper because that’d be
too much of a maintenance burden.  For “unusual” variants, I recommend
maintaining your own channel.  (This is something we did at Inria for
example with an Open MPI variant that includes the MPI1 compatibility
layer.)

Additionally, you can use things like ‘--with-input=openmpi=mpich’.  We
may eventually get support for “parameterized packages”, which will
allow users to choose between HDF5 variants from the command line:

  https://lists.gnu.org/archive/html/guix-devel/2020-11/msg00312.html

> 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?

For Guix proper, I think we should keep the number of HDF5 variants
stable.  We should remove old versions once they’re no longer needed by
any in-tree package.

> 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.
> And then there is MPICH...
>
> I would also like to see HDFView as a Guix package. We have a Spack package, but
> the Java story on Guix (I don't blame you ;-) is a little confusing.

That’s a different story :-) but please don’t hesitate to share your
experience, frustration, and questions regarding Java on the mailing
lists, I’m sure you’ll get some guidance.

> 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?

It’s great to get feedback from upstream; you can certainly help us make
wise(r) decisions regarding HDF5 packaging, in particular in deciding
which variants and versions make sense, what defaults are reasonable,
and how well they work in an HPC and non-HPC setting.

WDYT?  What changes would you like to see?

Thanks for your interest!

Ludo’.