[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

[Gerd Heber]

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?

In HDF5's case, we also use versions in a peculiar way, where the expectation is
that 1.8.x, 1.10.x, and 1.12.x, etc. version are not compatible for
end-user applications,
mostly because of API changes.

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

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?

Best, G.

On Tue, Mar 2, 2021 at 1:39 PM Ludovic Courtès <ludo@gnu.org> wrote:
>
> zimoun <zimon.toutoune@gmail.com> skribis:
>
> > On Tue, 2 Mar 2021 at 01:32, Gerd Heber <gerd.heber@gmail.com> wrote:
> >> On Mon, Mar 1, 2021 at 4:45 AM zimoun <zimon.toutoune@gmail.com> wrote:
> >
> >> > --8<---------------cut here---------------start------------->8---
> >> > (define-public hdf5-1.12-parallel-openmpi
> >> >   (package/inherit hdf5-parallel-openmpi
> >> >     (version (package-version hdf5-1.12))
> >> >     (source (package-source hdf5-1.12)))
> >> > --8<---------------cut here---------------end--------------->8---
> >
> >> Hey, thanks, very clever! Should I submit a new patch or is there a
> >> way to patch the patch?
> >
> > The usual way is to send a v2 which is the patch to apply to the Git
> > tree (and *not* a patch to apply to a patch to apply to the tree).
> >
> > However, personally I am not in favor to add to Guix proper too much
> > versions of variant packages; but that's just my humble opinion.
> > Instead, it could be submitted to specific channels, for instance
> > <https://gitlab.inria.fr/guix-hpc/guix-hpc> or any other listed in
> > Guix-HPC.
>
> In this particular case, I think the proposed variant is fine; it’s
> consistent with what we’re already doing with hdf5.
>
> Ludo’.