unofficial mirror of guix-patches@gnu.org 
 help / color / mirror / code / Atom feed
From: "Ludovic Courtès" <ludovic.courtes@inria.fr>
To: Gerd Heber <gerd.heber@gmail.com>
Cc: 46830@debbugs.gnu.org, zimoun <zimon.toutoune@gmail.com>
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
Date: Mon, 08 Mar 2021 15:01:42 +0100	[thread overview]
Message-ID: <87r1kpd9rt.fsf@gnu.org> (raw)
In-Reply-To: <CANnLdWHqJ+EhCgU_82Dn0PG=d4oUH-aGNM-FvsemCd3tOiZ1ug@mail.gmail.com> (Gerd Heber's message of "Wed, 3 Mar 2021 08:10:05 -0600")

Hi Gerd,

Gerd Heber <gerd.heber@gmail.com> 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’.




  parent reply	other threads:[~2021-03-08 14:03 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-28 13:33 [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
2021-02-28 22:42 ` Gerd Heber via web
2021-03-01 10:41 ` zimoun
     [not found]   ` <CANnLdWFK--F3vTC7R6WtUMYOKA-MAJCWj6LXS42mv-ZNKF63YA@mail.gmail.com>
2021-03-02  9:41     ` zimoun
2021-03-02 19:39       ` Ludovic Courtès
2021-03-03 14:10         ` Gerd Heber
2021-03-05  1:08           ` zimoun
2021-03-08 14:01           ` Ludovic Courtès [this message]
2023-09-13  9:29 ` bug#46830: Closing Andreas Enge

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87r1kpd9rt.fsf@gnu.org \
    --to=ludovic.courtes@inria.fr \
    --cc=46830@debbugs.gnu.org \
    --cc=gerd.heber@gmail.com \
    --cc=zimon.toutoune@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).