[PATCH] gnu: hdf5: Update to 1.12.0.

---

gnu/packages/maths.scm | 4 ++--

1 file changed, 2 insertions(+), 2 deletions(-)

On Tue, Dec 29, 2020 at 01:12:03PM +0100, Vincent Legoll wrote:

Thanks!

The variable name should be updated to reflect the new version, and any

packages using it would also need to be adjusted.

Can you send a revised patch?

Hello,

On Wed, Dec 30, 2020 at 3:19 AM Leo Famulari <leo@famulari.name> wrote:

oops,completely missed that, sorry.

Yep, I'll do.

Thanks for the review

--

Vincent Legoll

Hi,

On Wed, 30 Dec 2020 at 17:01, Vincent Legoll <vincent.legoll@gmail.com> wrote:

Please check that all the packages depending on hdf5-1.10 correctly

build with 1.12.0, for example: freecad, libmedfile, etc.

And also hdf5-parallel-openmpi which inherits from, so packages

depending on that too.

Therefore, instead it could be simpler to add a new variable hdf5-1.12

and use it as default with the variable hdf5.

All the best,

simon

Hello,

On Wed, Dec 30, 2020 at 7:35 PM zimoun <zimon.toutoune@gmail.com> wrote:

Is this specific to that package or should I always rebuild all the

dependencies (& their dependencies) for each package update ?

--

Vincent Legoll

On Tue, Jan 05, 2021 at 10:34:36AM +0100, Vincent Legoll wrote:

The packages which share a source should definitely be tested out. As

far as ones that depend on them test them out to your best ability. It

normally depends on computing power and whether they built previously or

not.

Some package groups have special needs. rust packages only really need

to pass their build phase, and anything that depends on them should just

keep working. I've never gotten a good result from java packages so I'll

build those out to the very end. Due to the way python works it can be

hit-or-miss.

--

Efraim Flashner <efraim@flashner.co.il> ????? ?????

GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351

Confidentiality cannot be guaranteed on emails sent or received unencrypted

Hi,

On Tue, 05 Jan 2021 at 10:34, Vincent Legoll <vincent.legoll@gmail.com> wrote:

I do not know if there is a rule. But hdf5 is used by many scientific

packages and so changing the default version needs some care, IMHO.

Upgrading the version could lead to annoying breakages and it is better

to fix them at this upgrading time than to discover them later.

Well, I am not sure about your initial intention with your patch,

a) add the new variable hdf5-1.12

b) change the variable hdf5-1.10 by hdf5-1.12 which means replace all

the occurrences of hdf5-1.10 and check everything builds; note the

default hdf5 is changed too so it is a lot of rebuilds

Some packages specifically depends on hdf5-1.8 so maybe some packages

also specifically require hdf5-1.10; I have not checked.

These 9 packages specifically use hdf5-1.10:

hdf5-parallel-openmpi, freecad, libmedfile, hdf5-blosc,

python-h5py, python-tables, sbcl-hdf5-cffi, r-rhdf5lib,

sra-tools

so they need special care, at least. :-)

My point is “guix refresh -l hdf5” says the upgrade could have an impact

on a couple of packages and I just wanted be sure that you were aware of

that. :-)

All the best,

simon

Hello,

Thanks for the explanation, I'll see if I can build

those & report here.

--

Vincent Legoll

Hello,

I tried to make it the default, but at least ecl-hdf5-cffi

did not rebuild properly, so I think the best way forward

would be to add 1.12.0 as a separate non-default version,

and then let the users of the dependent packages update

as they want / have tested. I'm not user of any of those...

Or completely drop my (random-)update.

--

Vincent Legoll

Hi Vincent,

Thank you for testing.

On Mon, 11 Jan 2021 at 18:57, Vincent Legoll <vincent.legoll@gmail.com> wrote:

This was my initial suggestion. :-)

On the other hand, if only one package is failing with 1.12.0, maybe

upgrade the default and keep the previous for this specific package

only.

All the best,

simon

Closing as duplicate of :

f601cdc6981888f55882c942dab413cb783caecc

--

Vincent Legoll