On Sun, Jun 06 2021, Ludovic Courtès wrote:

> Hi!
>
> Xinglu Chen <public@yoctocell.xyz> skribis:
>
>> On Fri, Apr 09 2021, Xinglu Chen wrote:
>>
>>> On Fri, Apr 09 2021, Léo Le Bouter via Guix-patches via wrote:
>>>
>>>> Is that an autogenerated tarball? I am under the impression that usage
>>>> of those is banned in GNU Guix, and that there's a lint pass for it.
>>>> What do you use these autogenerated tarballs for? Is the 'ls-remote'
>>>> command not enough to replace the version and hash?
>>>
>>> The GitHub updater fetches the autogenerated tarball so that's what I
>>> did as well.  I wasn't aware about the fact that we would like to avoid
>>> them.
>>>
>>>> GNU Guix uses shallow clones (AIUI) to save bandwidth, do you need
>>>> this to generate the hash? I encourage you use the same shallow clone
>>>> mechanism here, so it's more generic and not specific to Sourcehut.
>>>
>>> Ok, I will use shallow clones to make it more generic.
>>
>> Umm, the 'upstream-source-compiler' uses 'url-fetch' to fetch the url, I
>> guess we would have to make it support Git repositories first.
>
> Yes, that’s a limitation of (guix upstream) right now.
> ‘%method-updates’ was a first step in the direction of supporting Git
> repos.

One of the problems with adding support for Git repos in (guix upstream)
was that Libgit2 (and by extension Guile-Git) doesn’t provide an API for
verifying tags, the I only way I know of is to run ‘git verify-tag’ in
the shell.  There is a ‘git_commit_extract_signature’ API, but it only
for individual commits, and since the majority of people don’t sign
their commits it means that a most of the time its not going to be able
to verify the checkout.

> Now, I agree with Léo that (1) this is not SourceHut-specific, and (2)
> it should not download generated archives.
>
> Also, I’d prefer to have the code rely on Guile-Git to list tags rather
> than invoking ‘git’, if possible.

Libgit2 has a ‘git_tag_list’ API, though it doesn’t seem like Guile-Git
supports it.

  https://libgit2.org/libgit2/#HEAD/group/tag/git_tag_list

> Perhaps that code could leave in its own (guix import git) module or
> similar, rather than in (guix gnu-maintenance), which already has
> little to do with GNU maintenance at this point.  :-)

Yeah, I think that’s a good idea :)