The problem of packaging Minetest mods/games

[Jan <tona_kosmicznego_smiecia@interia.pl>]

Hello,

Recently I decided to update the Minetest package, which isn't a problem
itself, but I discovered the package fails to provide the default
minetest game. For those who don't know, Minetest is extensible by
desing - all you do is you put a modification/game into a folder -
usually /share/minetest/games or ~/.minetest/games and it is run by the
game engine.
I checked the source code and there's a non-public minetest-data
package, which provides the minetest_game and it contains this:

(arguments
     `(#:modules ((guix build utils))
       #:builder (begin
                   (use-modules (guix build utils))
                   (let ((install-dir (string-append
                                       %output
                                       "/share/minetest/games/minetest_game")))
                     (mkdir-p install-dir)
                     (copy-recursively
                       (assoc-ref %build-inputs "source")
                       install-dir)
                     #t))))

And this package is in the propagated-inputs fiend of the minetest
package, but it doesn't work.

I would like to understand why it doesn't work, fix it and learn
something new about Guix by the way :)

The second problem I encountered during examining the package was every
time I changed the path of the minetest_game in the minetest-data
package minetest was also recompiled, which took long time. (I thought
the path is improper)
My question is, what is the Guix way of dealing with such packages?
Imagine we have like 100 packaged minetest mods/games. Say I wanted to
add one, would I have to recompile the whole minetest package (C++),
despite the fact all mods are just Lua scripts put into folder and
interpreted by the engine?

Could we for example place the mods in the ~/.minetest/games folder?


Jan Wielkiewicz