Graft hooks

[Timothy Sample <samplet@ngyro.com>]

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