Re: Graft hooks

[Ludovic Courtès]

Hello Timothy,

Timothy Sample <address@hidden> skribis:

> address@hidden (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’.