Re: Package renpy broken?

[Wojtek Kosior via <help-guix@gnu.org>]

[-- Attachment #1: Type: text/plain, Size: 5332 bytes --]

> Hi Wojtek, thanks for your response and the useful links to learn how to 
> patch a package.

No problem :) I have no doubt you would reach all the information
anyway if you have just a bit of determination

> [...] I do wonder about other users of Ren'Py - particularly whoever
> packaged it first, did they ever get it working for them?
>
> [...]
>
> I do like packages which *just work* out of the box, and I feel the
> declarative approach should generally help with that.

I have the same feeling. I know of at least two things that might be
causing packages to break for end users even though they worked for
packagers.

Firstly, some dependency of the package might get updated and might be
causing problems. If this is the case, it might be useful to check the
Guix commit at which the desired package was initially added and use
`guix time-machine` to install the package with the exact dependency
versions it had back then... This is of course yet another workaround
and it'd be better to have the real problem fixed (if one has time for
that).

The other reason might be that the program behavior depends on some
files in user's home directory. Perhaps it worked for someone who for
example happened to have certain local configuration put in place by
another, non-Guix installation of the same program?

> 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.

I see this patch-on-patch stuff as personal quick hacks just to get
things working locally. As such, they won't harm the upstream Guix.

As to the maintenance burden of personal patches of one's self... well,
to me it still seems drastically smaller that in other distros I've
been using :)

> 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.
>
> [...]
> 
> What are your thoughts?

It would surely be cleaner. I just expect the "missing sources" issue
supposedly found by the previous packager might be something
non-obvious and harder to fix than it seems :/ But who knows?

> 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).

Maybe it had TFD sources bundled with itself?

Wojtek


-- (sig_start)
website: https://koszko.org/koszko.html
PGP: https://koszko.org/key.gpg
fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A

Meet Kraków saints!           #47: saint Stanisław ze Szczepanowa
Poznaj świętych krakowskich!  #47: święty Stanisław ze Szczepanowa
https://pl.wikipedia.org/wiki/Stanisław_ze_Szczepanowa
-- (sig_end)


On Sat, 29 Oct 2022 09:42:19 +0000
Christian Gelinek <christian.gelinek@mailbox.org> wrote:

> 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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]