GNU bug report logs - #50072
[PATCH WIP 0/4] Add upstream updater for git-fetch origins.

Previous Next

Full log

View this message in rfc822 format

From: Ludovic Courtès <ludo <at> gnu.org>
To: Maxime Devos <maximedevos <at> telenet.be>
Cc: Sarah Morgensen <iskarian <at> mgsn.dev>, 50072 <at> debbugs.gnu.org, zimoun <zimon.toutoune <at> gmail.com>
Subject: [bug#50072] [PATCH WIP 0/4] Add upstream updater for git-fetch origins.
Date: Thu, 06 Jan 2022 11:13:37 +0100

Maxime Devos <maximedevos <at> telenet.be> skribis:

> zimoun schreef op wo 05-01-2022 om 13:58 [+0100]:

[...]

>>  2) From my point of view, ’#:recursive?’ needs to be adapted in
>>  agreement with the discussion [1], quoting Ludo:
>> 
>>         Thinking more about it, I think confusion stems from the term
>>         “recursive” (inherited from Nix) because, as you write, it
>>         doesn’t necessarily have to do with recursion and directory
>>         traversal.
>> 
>>         Instead, it has to do with the serialization method.
>> 
>>         1: <http://issues.guix.gnu.org/issue/51307>
>> 
>>    And I do not have a strong opinion.  Just a naive remark.
>
> I don't think the arguments for (guix scripts hash) apply directly
> to (guix hash) -- (guix scripts hash) supports multiple serialisers:
>
>  * none (regular in (guix hash) terminology)
>  * git
>  * nar
>  * swh

I think IWBN eventually for ‘file-hash*’ to have a #:serializer
argument.  (guix scripts hash) would then become a thin layer above
(guix hash).

That #:serializer would have a default value, probably “none”, but no
“auto-detection” as this amount of guessing would make for a fragile
interface IMO.

(Perhaps ‘file-hash’ is too generic-sounding; for a ‘source-code-hash’
or similarly-named procedure, some defaults and guesswork would be more
obvious.)

Thanks,
Ludo’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.