Hello Timothy, Timothy Sample <[email protected]> skribis:
> [email protected] (Ludovic Courtès) writes: [...] >>>> I agree that this would be the right thing to do! (I’d really like to >>>> do it for GDB as discussed in <https://bugs.gnu.org/19973>.) >>>> >>>> Package properties would be the right way to make it extensible, but >>>> there are complications (notably we’d need to use gexps, but build >>>> systems don’t use gexps yet.) >>> >>> But soon, right? ;) >> >> Well, it’s complicated. :-) >> >> Also, I realized that some things, like the .gnu_debuglink and build-id >> hooks, don’t really fit in any package; they’re transverse. > > You’re right. Packages are the wrong place. What about build systems? > Maybe it makes sense (theoretically) to define graft hooks in build > systems, and then modify them (if necessary) using the “arguments” field > of a package. Isn’t it the GNU or Go build systems that are ultimately > responsible for these checksums? Shouldn’t it be their job to tell the > grafting code how to fix them? It’s not completely clearcut. For instance, the GCC toolchain can produce .gnu_debuglink and build-IDs, but the GCC toolchain and ‘gnu-build-system’ are not the only one doing so: ‘guile-build-system’, ‘go-build-system’, etc. could do that as well. So .gnu_debuglink and build-IDs are an example of something that doesn’t “belong” to any single package or build system, I think. [...] >> Regarding timestamps: I guess there’s no problem since timestamps are >> reset in the store. > > Whoops! I didn’t 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’t 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 “share/racket” as the heuristic to > determine if it should run. > > Maybe I will package a Racket library, too, so I can test it. Great, thank you! Ludo’.
