From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: Graft hooks Date: Fri, 24 Aug 2018 12:09:44 +0200 Message-ID: <87pny8qdnb.fsf@gnu.org> References: <87k1ovbc0t.fsf@ngyro.com> <87y3d1h05e.fsf@gnu.org> <87k1ojafqa.fsf@ngyro.com> <874lfmh477.fsf@gnu.org> <87y3cy8db6.fsf@ngyro.com> 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]:44961) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ft92O-0001DE-GK for guix-devel@gnu.org; Fri, 24 Aug 2018 06:09:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ft92J-0000rA-Vz for guix-devel@gnu.org; Fri, 24 Aug 2018 06:09:52 -0400 In-Reply-To: <87y3cy8db6.fsf@ngyro.com> (Timothy Sample's message of "Wed, 22 Aug 2018 14:29:49 -0400") 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: Timothy Sample Cc: guix-devel@gnu.org Hello Timothy, Timothy Sample skribis: > ludo@gnu.org (Ludovic Court=C3=A8s) writes: [...] >>>> I agree that this would be the right thing to do! (I=E2=80=99d really= like to >>>> do it for GDB as discussed in .) >>>> >>>> Package properties would be the right way to make it extensible, but >>>> there are complications (notably we=E2=80=99d need to use gexps, but b= uild >>>> systems don=E2=80=99t use gexps yet.) >>> >>> But soon, right? ;) >> >> Well, it=E2=80=99s complicated. :-) >> >> Also, I realized that some things, like the .gnu_debuglink and build-id >> hooks, don=E2=80=99t really fit in any package; they=E2=80=99re transver= se. > > You=E2=80=99re right. Packages are the wrong place. What about build sy= stems? > Maybe it makes sense (theoretically) to define graft hooks in build > systems, and then modify them (if necessary) using the =E2=80=9Carguments= =E2=80=9D field > of a package. Isn=E2=80=99t it the GNU or Go build systems that are ulti= mately > responsible for these checksums? Shouldn=E2=80=99t it be their job to te= ll the > grafting code how to fix them? It=E2=80=99s not completely clearcut. For instance, the GCC toolchain can produce .gnu_debuglink and build-IDs, but the GCC toolchain and =E2=80=98gnu-build-system=E2=80=99 are not the only one doing so: =E2=80=98= guile-build-system=E2=80=99, =E2=80=98go-build-system=E2=80=99, etc. could do that as well. So .gnu_deb= uglink and build-IDs are an example of something that doesn=E2=80=99t =E2=80=9Cbelong= =E2=80=9D to any single package or build system, I think. [...] >> Regarding timestamps: I guess there=E2=80=99s no problem since timestamp= s are >> reset in the store. > > Whoops! I didn=E2=80=99t mean the file metadata, I meant in the bytecode= files > themselves. Also, I only saw the changes in diffoscope and assumed they > were timestamps. I looked more closely and realized they were more > checksums that I didn=E2=80=99t notice before (it should have been obvious > because they are 20 bytes...). They are supposed to be updated. > Nothing to see here. :) OK. :-) > Following my note above, I think I will try and finish my update code in > Guile, and then use the existence of =E2=80=9Cshare/racket=E2=80=9D as th= e heuristic to > determine if it should run. > > Maybe I will package a Racket library, too, so I can test it. Great, thank you! Ludo=E2=80=99.