Hi Wojtek, thanks for your response and the useful links to learn how to
patch a package.
Once you grasp a bit of it, you should be able to define your own
variant of the Ren'Py package. One without the bug.
That would probably be the easiest fix, but I do wonder about other
users of Ren'Py - particularly whoever packaged it first, did they ever
get it working for them?
I realize it's probably a bit discouraging to come to a new distro and
find out you need to learn packaging to utilize it.
I guess switching distros is always going to cause some friction, so I
was partly prepared for that.
Yet, honestly, Guix is a geeky package manager - you can only benefit from its
super-powers once you're yourself Guix geek ¯\_(ツ)_/¯
You're right in that, and it also seems to have some really compelling
features that motivated me to switch and which (hopefully) make this
learning experience worthwhile. On the other hand, I do like packages
which *just work* out of the box, and I feel the declarative approach
should generally help with that. As a newcomer I do have the concern
that this "geekiness" can also lead to a pile of patches on top of each
other (in this case, the patch to remove TFD and then another to make
the package work again without it) that I feel would increase the
maintenance burden rather than decreasing it beyond the short term.
Please tell me if what I said doesn't match the deeper philosophy behind
Guix for some reason or another.
Looking at my Ren'Py issue, I am wondering whether the cleaner approach
would be to package TFD as a separate package (I think zlib counts as a
Free Software license) and make it a dependency of Ren'Py, hoping that
will fix the issue. Maybe other packages like rust-tinyfiledialogs
could benefit from such a package as well (I am wondering how users of
that are currently actually using TFD).
What are your thoughts?
Christian