From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark H Weaver Subject: Re: =?utf-8?Q?=E2=80=98computed-origin-method=E2=80=99?= for IceCat and ungoogled-chromium Date: Fri, 30 Aug 2019 18:41:49 -0400 Message-ID: <87woeuwa0n.fsf@netris.org> References: <87h85zh7ij.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:470:142:3::10]:36865) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i3pbF-0002rS-1I for guix-devel@gnu.org; Fri, 30 Aug 2019 18:42:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1i3pbD-0003gT-RO for guix-devel@gnu.org; Fri, 30 Aug 2019 18:42:32 -0400 In-Reply-To: <87h85zh7ij.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Fri, 30 Aug 2019 01:33:08 +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 Hi Ludovic, Ludovic Court=C3=A8s writes: > Hello Mark & Marius! > > Somehow I hadn=E2=80=99t noticed the clever trick with =E2=80=98computed-= origin-method=E2=80=99 > in IceCat and ungoogled-chromium, and it came to me as a shock today. > ;-) Yes, I probably should have brought wider attention to what I did there. Sorry about that. Initially I needed it on short notice for the IceCat-60.5.0 security update, which turned out to be impractical to do by my earlier method, where I would cherry-pick dozens of patches from the upstream repo, because I found to my dismay that Mozilla had reindented the entire source tree, including the ESR branch. Anyway, the purpose of =E2=80=98computed-origin-method=E2=80=99 is simply t= o work around some limitations in 'patch-and-repack' and snippets. Most importantly, I needed to produce an output directory and tarball name starting with "icecat-" from an original source tarball named "firefox-...". > I stumbled upon it while traversing packages with =E2=80=98guix lint=E2= =80=99 because > they violated the assumption that the =E2=80=98sha256=E2=80=99 field of <= origin> is > always a bytevector. > > I suspect this could be rewritten by using =E2=80=98computed-file=E2=80= =99 instead of > . This should be clearer, I think, notably because it would > avoid exposing a =E2=80=9Cnon-conforming=E2=80=9D . > > WDYT? I'd be glad to switch to another mechanism, but I'm not sure =E2=80=98computed-file=E2=80=99 can be made to do what I need. The problem= there is that =E2=80=98computed-file=E2=80=99 needs a G-expression. I found that I = needed to delay evaluation of the G-expression used to produce 'icecat-source', to cope with our widespread cyclic module dependencies. If I remember correctly, the problem is that when gnuzilla.scm is loaded, the modules that it depends on may not have been loaded yet, due to the circular module dependencies, so we generally run into problems unless all references to imported packages are delayed. That's why =E2=80=98computed-origin-method=E2=80=99 takes a gexp _promise_ instead of = a gexp. Also, I wasn't sure if all of the code that pattern matches on package 'source' fields handle non-origins properly. Finally, I should mention that in addition to IceCat and ungoogled-chromium, our linux-libre source tarballs are also now generated using =E2=80=98computed-origin-method=E2=80=99. That raises an a= dditional issue: in the case of our 'linux-libre' packages, we apply patches *after* running the code that generates the pristine linux-libre tarball. With =E2=80=98computed-origin-method=E2=80=99, I can add 'patches= ' to that origin type, and it will do what I need. I'm not sure if this can be done with =E2=80=98computed-file=E2=80=99 or snippets, even if the other li= mitations are addressed. What do you think? Mark