[bug#72912] [PATCH 0/1] Update Minetest to 5.9.0 (again)

[Jan Wielkiewicz <tona_kosmicznego_smiecia@interia.pl>]

On Sat, 31 Aug 2024 13:40:02 +0200
Liliana Marie Prikler <liliana.prikler@gmail.com> wrote:

> Am Samstag, dem 31.08.2024 um 12:52 +0200 schrieb Jan Wielkiewicz:
> > Sending again after sending guix lint messages.
> Note for future submissions: it's okay (and even expected) to use --
> reroll-count while sending the revised patch to the same address as
> the original one. 

Okay, will do so. I missed that in documentation.

> > Minetest got updated to 5.9.0. This was a big update with major
> > changes.  Minetest Game (MTG) got dropped - is not longer the
> > official game for the Minetest engine, and got debundled from
> > default Minetest (engine) shipped to players. Hence I'm debundling
> > it from this Guix package renamed from "minetest-data" to
> > "minetest-minetest- game" and deprecated the former package.
> That's a somewhat unfortunate name.  Is there no better name to
> choose? Is there a reason not to use "minetest-game" for example?

The minetest-something convention is for packages that are either
games for minetest or mods for any minetest game. Minetest - the engine
executes games. Previously "Minetest Game" was the default game for
Minetest (the engine), but is not anymore. A similar example would be a
game called "MineClone" for Minetest, the package is then called
minetest-mineclone. But "Minetest Game" is indeed the name of the
ex-default game, hence minetest-minetest-game. "minetest-game" would
suggest it's a game for minetest named "game" also could make it
possible to confuse it with simply "minetest" - the engine.
The name of the package: https://github.com/minetest/minetest_game

I know it's convoluted, but the naming ambiguity is inherited from the
upstream project. I believe this redundant name makes it clearer.

> > In this release irrlicht-for-minetest got merged into Minetest's
> > tree, so I'm deprecating the package. I also had to adjust the
> > minetest build system to use the new "minetest-minetest-game"
> > package for testing. MTG also entered maintenance-only mode and
> > became a rolling release, so I picked the latest commit from the
> > master branch for it instead of git tags.
> We also like to unbundle such dependencies.  Is there a way forward
> for doing so?

There's no unbundling to be done here. Minetest was the sole user of
irrlicht-for-minetest. Minetest developers moved irrlicht directly into
the game's code and the two components are tightly coupled. The
irrlicht fork has been archived: https://github.com/minetest/irrlicht
So the irrlicht-for-minetest code that was moved into Minetest is now
considered to be a non-replaceable non-modular part of the code that's
not meant to be anywhere but in Minetest only. On top of that it's not
longer possible to use upstream irrlicht in Minetest, hence the
decision to move the fork into the game's tree directly.

> 
> > Minetest build system actually makes a pretty ugly assumption -
> > that all minetest mods are mods for MTG, while the game supports
> > mods for any minetest game (for example Voxelibre, Nodecore and
> > such). So testing all mods against MTG makes no sense, but it will
> > addressed in future commits.
> Sounds like a plan.
> 
> Cheers

Hope this makes it clear.

--

Jan Wielkiewicz