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

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

Ping!  :-)

Ludovic Courtès <ludo@gnu.org> skribis:

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