Re: Package renpy broken?

[Christian Gelinek <christian.gelinek@mailbox.org>]

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