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

Previous Next

Package: guix-patches;

Reported by: Jesse Gibbons <jgibbons2357 <at> gmail.com>

Date: Fri, 4 Sep 2020 04:34:02 UTC

Severity: normal

Tags: patch

Done: Ludovic Courtès <ludo <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


Message #20 received at 43194 <at> debbugs.gnu.org (full text, mbox):

From: Jesse Gibbons <jgibbons2357 <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 43194 <at> debbugs.gnu.org
Subject: Re: [bug#43194] [PATCH] gnu: publicly define freedink-engine and
 freedink-data
Date: Thu, 24 Sep 2020 21:55:01 -0600
[Message part 1 (text/plain, inline)]
Sorry it took so long. Updated patch is attached.

-Jesse.

On 9/24/20 9:18 AM, Ludovic Courtès wrote:
> Ping!  :-)
>
> Ludovic Courtès <ludo <at> gnu.org> skribis:
>
>
...
>>> -> 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.
The patch removes both desktop files.
>> OK, makes sense—thanks for explaining.

>>>>>    (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.
The patch fixes this.

>>> 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.
The patch does not do this. For now, I don't have the time (and probably 
won't have much time until late December), so I'll leave it as a to-do 
item for anyone who wants to accomplish this.

-Jesse

[0001-gnu-publicly-define-freedink-engine-and-freedink-dat.patch (text/x-patch, attachment)]

This bug report was last modified 4 years and 291 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.