unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
* The problem of packaging Minetest mods/games
@ 2020-05-19 21:05 Jan
  2020-05-19 22:34 ` Julien Lepiller
                   ` (2 more replies)
  0 siblings, 3 replies; 6+ messages in thread
From: Jan @ 2020-05-19 21:05 UTC (permalink / raw)
  To: guix-devel

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


^ permalink raw reply	[flat|nested] 6+ messages in thread
* The problem of packaging Minetest mods/games
@ 2020-05-19 22:36 Leo Prikler
  2020-05-20  3:46 ` Mike Gerwitz
  0 siblings, 1 reply; 6+ messages in thread
From: Leo Prikler @ 2020-05-19 22:36 UTC (permalink / raw)
  To: tona_kosmicznego_smiecia; +Cc: guix-devel

Hello Jan,

> 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 :)
My guess is, that minetest searches in 
  /gnu/store/<hash>-minetest/share/...
when the actual path is
  /gnu/store/<other-hash>-minetest-data/share/...
If you just want to get the base game to work, it should probably be
okay to add a symlink instead of propagating the input, but this
obviously won't work for third party extensions.

> 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?
The canonical Guix way is to look for environment variables to set
(usually called STUFF_WERE_LOOKING_FOR_PATH) and add a search path
specification for that in the original package.  Take gstreamer as an
example, for which we define GST_PLUGIN_SYSTEM_PATH.

If the game does not yet support such variables (it appears, Minetest
does indeed have MINETEST_SUBGAME_PATH, but no MINETEST_MOD_PATH in
case you need the latter), consider patching the game itself so that it
does.  If you're lucky, you can even convince people to accept your
patch upstream.  If not or if it's really Guix-specific (as in the case
of GUIX_GTK3_PATH for example), we'll have to carry around that patch
in the Guix tree and keep it updated.

> Could we for example place the mods in the ~/.minetest/games folder?
That's not very functional of you.  In theory, you can put stuff there,
but not using Guix.  As an example, Stepmania reads all its
configuration, data and cache from ~/.stepmania-<version>, so that's of
course where I put the data – data, that is already unfit to be managed
by Guix due to licensing issues, mind you.  In the case of Minetest
mods/games, that folder quickly gets stale however, so I'd not suggest
doing so unless you really need to.

Regards,
Leo

PS: minetest-data sounds like a good candidate for copy-build-system.
PPS: Ignore the older (non-public) mail I sent you mentioning
MINETEST_GAME_PATH instead of MINETEST_SUBGAME_PATH.  At that point, I
had not yet encountered that variable in my research.



^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2020-05-20 16:50 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-05-19 21:05 The problem of packaging Minetest mods/games Jan
2020-05-19 22:34 ` Julien Lepiller
2020-05-20  0:47 ` Ricardo Wurmus
2020-05-20 16:49 ` Jan
  -- strict thread matches above, loose matches on Subject: below --
2020-05-19 22:36 Leo Prikler
2020-05-20  3:46 ` Mike Gerwitz

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).