From mboxrd@z Thu Jan 1 00:00:00 1970 From: taylanbayirli@gmail.com (Taylan Ulrich =?utf-8?Q?Bay=C4=B1rl=C4=B1?= =?utf-8?Q?=2FKammer?=) Subject: Re: [PATCH] gnu: Add higan. Date: Wed, 08 Jun 2016 16:21:13 +0300 Message-ID: <87fusn7r5i.fsf@T420.taylan> References: <87fustalcn.fsf@T420.taylan> <87porrkgab.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:33607) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bAdQB-0000bB-0X for guix-devel@gnu.org; Wed, 08 Jun 2016 09:21:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bAdQ5-0003At-Q7 for guix-devel@gnu.org; Wed, 08 Jun 2016 09:21:21 -0400 In-Reply-To: <87porrkgab.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Wed, 08 Jun 2016 14:37:32 +0200") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Ludovic =?utf-8?Q?Court=C3=A8s?= Cc: guix-devel@gnu.org ludo@gnu.org (Ludovic Court=C3=A8s) writes: > taylanbayirli@gmail.com (Taylan Ulrich "Bay=C4=B1rl=C4=B1/Kammer") skribi= s: > >> 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=E2=80=99s OK to have a couple of patc= hes, > but it=E2=80=99s 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 =E2=80=9Creal=E2=80=9D 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=E2=80=99. Taylan P.S.: I already pushed a patch yesterday, but can push fixes as desired.