GNU bug report logs - #43061
freedink package is needlessly complex

Previous Next

To reply to this bug, email your comments to 43061 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

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

From: Jesse Gibbons <jgibbons2357 <at> gmail.com>
To: bug-guix <at> gnu.org
Subject: freedink package is needlessly complex
Date: Wed, 26 Aug 2020 10:55:10 -0600

TL;DR The freedink package is defined in a complex way that breaks 
guix's custom source build features and the GUI wrapper.

The freedink package wraps the freedink-engine and freedink-data 
packages so the resulting executable bin/freedink runs the freedink 
engine pointed at the output of freedink-data. The wrapped packages are 
not exported from gnu/packages/games.scm. Because of these two design 
choices,

-> guix build --sources=all freedink does not list the freedink-data source.

-> the only way to get the freedink-data source is to run guix build 
--sources=transitive freedink. This is not ideas because it gets the 
source for bash as well.

-> "guix build --with-source=freedink-data=..." has no effect on 
freedink, so guix cannot be used to facilitate freedoms 1 and 3 with 
freedink, unlike most other packages. To be clear,  freedoms 1 (to 
modify the software) and 3 (to distribute the modified software) are not 
violated, but a very nice feature of guix that makes them less complex 
does not work with freedink. To achieve a guix install or pack of 
freedink as it is currently defined with custom sources and/or data, one 
must define new freedink packages, which is more work than one or two 
simple command-line flags.

-> freedink-dfarc does not find "dinkedit" or "dink", which are links to 
binaries built in freedink-engine. Once again, freedoms 1 and 3 are a 
little more difficult to exercise than reasonably expected given what 
guix provides, but not violated. To point freedink-dfarc to the correct 
binaries, one must copy the store location in the wrapper script 
produced by freedink. Obviously, this store location will not 
automatically be updated when freedink-engine is upgraded.

-> Because the wrapper hard-codes a location to look for the data, I 
suspect (but have yet to confirm) that an attempt to use freedink-dfarc 
to build a modified version of freedink will ultimately throw an error.

There must be a way to re-package freedink such that:

1) It works with the custom source build features provided by guix.

2) The guix wrapper freedink-dfarc is neither necessary for running 
freedink, nor broken when used to run freedink.

The solution could be as simple as publicly exposing freedink-engine and 
freedink-data, and redefining the freedink package to simply take the 
two packages as inputs and produce a wrapper script. The script should 
probably have a name other than "freedink" or "dink" so all three 
packages can optionally co-exist in the same profile without a name 
conflict. I will try this solution and send a patch if it passes the 
following tests:

-> The sources for all freedink-related packages can be produced with 
"guix build --source" or "guix build --sources=all"

-> all freedink-related packages can be installed and packed with 
modified local sources specified by --with-source

-> installing freedink does not add anything to the profile other than a 
wrapper script.

-> There is no name conflict between the executables provided by 
freedink-engine and freedink

If anyone knows why freedink is packaged the way it is and thinks it is 
better that way, I want to know your reasons before I begin to attempt 
to fix this issue, because those reasons could lead me to a different 
approach.

I suspect freedink is not the only package with these issues.

-Jesse

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

From: Ludovic Courtès <ludo <at> gnu.org>
To: Jesse Gibbons <jgibbons2357 <at> gmail.com>
Cc: 43061 <at> debbugs.gnu.org
Subject: Re: bug#43061: freedink package is needlessly complex
Date: Fri, 28 Aug 2020 16:07:34 +0200

Hi Jesse,

Jesse Gibbons <jgibbons2357 <at> gmail.com> skribis:

> If anyone knows why freedink is packaged the way it is and thinks it
> is better that way, I want to know your reasons before I begin to
> attempt to fix this issue, because those reasons could lead me to a
> different approach.

I reviewed the initial submission and tweaked it afterwards but… I don’t
remember.

However, if you propose a patch to improve the situation, I’ll gladly
apply it.  How does that sound?  :-)

Thanks,
Ludo’.

Previous Next

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