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
