ludo@gnu.org (Ludovic Courtès) writes:

> taylanbayirli@gmail.com (Taylan Ulrich "Bayırlı/Kammer") skribis:
>
>> ludo@gnu.org (Ludovic Courtès) writes:
>
> [...]
>
>>> 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.
>
> Yes, I think it would be more appropriate.

I contacted the maintainer of the repo and asked them to add a tag,
which is done now.

Note: apparently the author re-released 098 with a hotfix very soon
after releasing it, without making a version change.  In the repository,
this is tagged as 098b, which I use here.  I.e. this is not a true
version update; we were already using "this 098".

>>>>   * 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.
>
> Hmm OK.  What do other distros do?

More or less the same thing; it's sanctioned by the developers even
though it's acknowledged not to be a particularly good solution.  Here
we see Arch do the same:

https://git.archlinux.org/svntogit/community.git/tree/trunk/higan?h=packages/higan

(Though this one seems to have a bug because they copy things to
~/Emulation instead of the new ~/.local/share.  I'm confident that
~/.local/share is the right location in the latest release.  Also for
the cheats.bml file.)

Here's a patch that, in addition to switching the repo, adds a patch
removing a -march=native flag (which I assume would break
cross-compilation), and passes the make flag "profile=balanced" to make
higan less CPU intensive by emulating a bit less accurately (it was
running too slow on my i5, so this should be a better default).

I just saved a princess from an evil wizard with this so I can confirm
it runs smooth now.