Hello Timothy, Timothy Sample <samp...@ngyro.com> skribis:
> l...@gnu.org (Ludovic Courtès) writes: [...] >> Next we can fix build IDs similarly (see <https://bugs.gnu.org/25752>), >> and maybe the Racket CRC issue that Timothy and Chris looked at >> recently, and maybe the Java manifest issue as well (is it still >> relevant?). > > The only concern I have is the level at which the hooks operate. In my > draft patch¹ I had the hooks running both on the client side and the > build side. This made it possible to get a bit more information about > the derivation being grafted. If everything happens at the build level > based on outputs, we will only be able to look at the structures and > names of the outputs. Yes, I agree that your proposal had the appeal of being possibly more extensible that what I posted here. However, as I wrote there, there are hooks that we’ll always want to run, independently of the input packages, such as the .gnu_debuglink and build-ID hooks; also, it costs nothing to have them unconditionally, we only pay for their functionality when candidate files exist. > That being said, this is probably okay. The Racket hook will just have > to check for “share/racket” to determine if it runs (and fail safely if > anything is amiss). Yes, that should work well enough. Thanks for your feedback! Ludo’.
