unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Graft hooks
@ 2018-08-12 19:49 Timothy Sample
  2018-08-13  0:28 ` Christopher Lemmer Webber
  2018-08-20  9:12 ` Ludovic Courtès
  0 siblings, 2 replies; 13+ messages in thread
From: Timothy Sample @ 2018-08-12 19:49 UTC (permalink / raw)
  To: guix-devel

Hi Guix,

I just submitted a patch for <https://bugs.gnu.org/30680>, but now I’m
wondering if there isn’t a more general way to solve the problem.

The bug has to do with grafting and checksums.  I know three bugs that
follow this theme: the one above (Racket), <https://bugs.gnu.org/19973>
(GDB), and <https://bugs.gnu.org/25752> (Go).  The basic problem is that
these packages store checksums of files during build time.  If they get
updated due to grafting, the files change, but the checksums do not.
The checksums become invalid, which causes other problems like trying to
update files in the store or asserting that debugging information is
invalid.

The patch I submitted makes Racket assume that files in the store are
good.  It patches Racket to skip checksum validation if it is checking a
file in the store.  A similar approach could be taken for GDB and Go.

It occurs to me that if we had some way to run package-specific code
during grafting we could solve problems like this easily and without
patching software that is not broken.

The basic idea would be to add a field (or use a property) to the
package record.  Let’s call it “graft-hook”.  It would be Scheme code
that gets run after grafting takes place, giving us a chance to patch
special things like checksums.  The hook would be passed the list of
files that were been modified during grafting.  Then, in the Racket
package for example, I could write a graft-hook that updates the SHA-1
hash of each of the modified source files.

Since grafting is done at the derivation level, the hook code would have
to be propagated down from the package level.  I haven’t looked at all
the details yet, because maybe this is a bad idea and I shouldn’t waste
my time!  :)  My first impression is that it is not too tricky.

Are these problems too specialized to deserve a general mechanism like
this?  Let me know what you think!


-- Tim

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2018-08-24 22:01 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-08-12 19:49 Graft hooks Timothy Sample
2018-08-13  0:28 ` Christopher Lemmer Webber
2018-08-13  7:19   ` Gábor Boskovits
2018-08-20  9:12 ` Ludovic Courtès
2018-08-21 15:42   ` Timothy Sample
2018-08-22 14:21     ` Ludovic Courtès
2018-08-22 18:29       ` Timothy Sample
2018-08-24 10:09         ` Ludovic Courtès
2018-08-22 19:15       ` Christopher Lemmer Webber
2018-08-23  7:15       ` Mark H Weaver
2018-08-23  9:54         ` Gábor Boskovits
2018-08-24 10:17         ` Ludovic Courtès
2018-08-24 21:59           ` Mark H Weaver

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).