[bug#43194] [PATCH] gnu: publicly define freedink-engine and freedink-data

["Ludovic Courtès" <ludo@gnu.org>]

Hi,

Jesse Gibbons <jgibbons2357@gmail.com> skribis:

>>> The attached patch publicly defines freedink-engine and
>>> freedink-data. This resolves many of the issues described in
>>> #43061. This patch, combined with patch #43193(sent earlier today),
>>> can close #43061.
>> Now I’m confused: how does it help to make freedink-{engine,data}
>> public?
> Other than making guix more consistent in publicly defining game data
> packages (0ad-data and megaglest-data are public, and I like that -- I
> could write a good article about why, which I think would be a worthy
> entry in the guix blog, especially after #43193 is applied), there are
> 4 reasons for this change:
>
> -> freedink-dfarc has problems locating the editor, installed in
> freedink-engine. I guess we could also fix this by making
> freedink-engine an input to freedink-dfarc and splicing a reference to
> it into the default configuration?
>
> -> Unless freedink-data is public, `guix build --source freedink-data`
> fails, and `guix build --sources=all freedink` does not build a source
> for freedink-data. I think future users who want to alter the freedink
> data would appreciate the ability to use guix to get the data. Also,
> it's pointless to use the editor on the installed freedink-data
> because it's read-only when it's installed.
>
> -> Back when I was fixing freedink, I found it difficult to debug
> without freedink-engine being public, because freedink does nothing
> with the freedink-engine source.
>
> -> Freedink-engine installs desktop files to launch freedink without
> freedink-dfarc or the console. This is actually a new issue I will
> address in an updated patch: the desktop files fail because the data
> location is not hard-coded. I think the freedink desktop file can be
> patched if freedink-data is an input, but, like I said above, it's
> pointless to use dinkedit on a read-only directory, so I intend to
> remove it.

OK, makes sense—thanks for explaining.

>>> >From 583215aced9b557d6f4e54b290e788d33880c03c Mon Sep 17 00:00:00 2001
>>> From: Jesse Gibbons <jgibbons2357+guix@gmail.com>
>>> Date: Wed, 26 Aug 2020 21:38:24 -0600
>>> Subject: [PATCH v1 1/1] gnu: publicly define freedink-engine and freedink-data
>>>
>>> * gnu/packages/games.scm: (freedink-engine): make public
>>> (freedink-data): make public
>> [...]
>>
>>>   (define-public freedink
>>>     ;; This is a wrapper that tells the engine where to find the data.
>>> -  (package (inherit freedink-engine)
>>> +  (package ;(inherit freedink-engine)
>> Is it intended?  Looks like inheriting avoids duplicating fields, no?
>
> Oops! I did not intend to leave (inherit freedink-engine) in a
> comment. I initially commented it out because freedink does nothing
> with the source anyway, and I wanted to see what would happen if I
> removed the inheritance. I guess I forgot to remove the semicolon and
> other additions.

OK.  If you send an updated patch, I’ll happily apply it, then!

> As noted above, it is easiest to use freedink-dfarc to launch the
> editor, but freedink-dfarc must be told what editor to use, and it is
> easier to identify it if the editor is installed in a profile (or
> included as an input). Also, freedink-engine includes (broken) desktop
> files. Since freedink just installs a wrapper script around the
> engine, and does not include the editor or any desktop files, perhaps
> it would be better to put the wrapper script in freedink-engine (thus
> fixing the desktop file), completely remove the freedink package, and
> rename "freedink-engine" to just "freedink"? But freedink-dfarc would
> still need to be able to launch freedink without pointing to any
> read-only data if a user wants to test the edited freedink data.

Maybe, sounds like a reasonable option.

Thank you,
Ludo’.