guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] gnu: Add higan.


From: Taylan Ulrich Bayırlı/Kammer
Subject: Re: [PATCH] gnu: Add higan.
Date: Wed, 08 Jun 2016 16:21:13 +0300
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

address@hidden (Ludovic Courtès) writes:

> address@hidden (Taylan Ulrich "Bayırlı/Kammer") skribis:
>
>> Some things to note about this package & questions:
>>
>> - There's no official VCS repo and the author doesn't want automated
>>   tools to download files from his homepage; there's an unofficial git
>>   repo at GitLab but I found it unsuitable so I'm hosting the sources
>>   specifically for Guix at GitHub now:
>>
>>   https://github.com/TaylanUB/higan
>
> In what sense is it unsuitable?  It’s OK to have a couple of patches,
> but it’s not quite OK to host a fork of the upstream package, IMO (at
> the very least, it can create confusion and make it harder to see how it
> differs from the “real” package.)

The repo is just for having a consistent place from which the source can
be fetched, as the author doesn't want source bundles to be downloaded
from his website.  No changes to the code are made.

The repo at GitLab didn't seem to tag releases properly.  That being
said, now that I look at it, it seems more like an oversight for v098.
Other releases seem to be tagged quite consistently:

    https://gitlab.com/higan/higan/tags

Should we use that repo instead?  It's a bit more official than mine.

>>   * The program insists on looking in ~/.local/share for some data files
>>     that are actually installed in $prefix/share; does my strategy here
>>     look OK, in that I wrap the executable to copy the data files into
>>     ~/.local/share every time the program is run?
>
> Sounds like a sledgehammer no?  :-)
>
> If those files are immutable, what about patching Higan to look for
> those files in $datadir instead?

Apparently, the files that are part of the distribution are pure data
files, i.e. fine to be read-only.  However, the directory hierarchy of
which they're a part needs to be writable, as higan creates further
files there.  With that cp -r, the directory hierarchy is made sure to
be there, and the data files made sure to be up to date.

Although I didn't look too closely at the sources, patching higan to do
things differently would presumably be a nontrivial task, since it seems
bent on doing things in terms of this directory structure that contains
both pure data and read-write data files.

> Thanks, and sorry for the delay!

No problem, thanks for the review. :-)

> Ludo’.

Taylan


P.S.: I already pushed a patch yesterday, but can push fixes as desired.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]