Hello!

Le dimanche 29 mai 2022 à 15:48 +0200, Liliana Marie Prikler a écrit :
> Am Sonntag, dem 29.05.2022 um 14:47 +0200 schrieb Vivien Kraus:
> > Subject: [PATCH v1 1/8] gnu: minetest: Update to 5.5.1.
> > 
> > * gnu/local.mk (dist_patch_DATA): Remove minetest-add-
> > MINETEST_MOD_PATH.patch.
> > * gnu/packages/patches/minetest-add-MINETEST_MOD_PATH.patch: Delete
> > it.
> > * gnu/packages/minetest.scm (irrlichtmt): New variable.
> > (minetest): Update to 5.5.1.
> > [patches]: Remove patch.
> > [configure-flags]: find irrlichtmt and zstd.
> > [inputs]: Replace irrlicht with irrlichtmt, add zstd.
> > (minetest-data): Update hash.
> I'd name "irrlichtmt" to "irrlicht-for-minetest" and perhaps split
> this
> patch into two.  Even if they need to be bumped "at once" later, I
> don't think this holds for the initial introduction.

I renamed the fork, and I split the commit as: introduce the fork, and
then (update minetest + use irrlicht-for-minetest). If I split the
minetest update commit further, it will create a broken commit. I was
told on #guix that I should not create such commits. Quoting nckx:

    vivien: No, each commit should result in a sane state whenever
possible.

> > * gnu/packages/minetest.scm (minetest-basic-materials): Update to
> > 2022-03-28 (commet 9d55f991…).
> > [snippet]: Make sound_api_core a dependency, not a submodule.
> Again doing two things at once.  I think it'd be wiser to first do
> the
> updates, then add minetest-sound-core, then add the snippets.  WDYT?

minetest-sound-core is introduced as a submodule for the
basic_materials update. So the code for it is not present at all. If I
first update basic_materials, then the tests will fail because it can’t
find sound_core. Do you mean that I should first try to respect the
will of the author and add it as a submodule (I don’t know how to do
that) and then take it out as a separate package?

> ¹ I did not check for hash mismatches or ContenDB version
> equivalence.

I just looked up the date and found a the commit in github that was
there (usually contentdb reports the next day as the github commit). Is
there something more to do?

> ² As pointed out by Maxime elsewhere in the mailing list, Minetest
> packages usually have flaky tags in their forges, so someone needs to
> look closer at whether this is going to break in the future.

Yes. Mesecons was using version numbers and then the latest tag is a
date. Given that it’s April 1st, maybe there’s something funny occuring
here, but the changes around that day looked reasonable to my untrained
eye. However, one thing I didn’t notice at first was the drop of the +
in the license. Sorry.

Vivien