Hi Gerd, On Wed, 03 Mar 2021 at 08:10, Gerd Heber 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. 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