Custom sha256 updaters ?

Custom sha256 updaters ?

[Nicolas Graves]

Has there already been some discussion about custom hash updaters? I
have written an import module for libreoffice, and we have access to the
sha256 hash in for example

https://download.documentfoundation.org/libreoffice/src/24.2.6/libreoffice-24.2.6.2.tar.xz.sha256

which would make it trivial to update without having to download 267MiB
of data twice.

However, %method-updates doesn't seem to allow such a flexibility for
now. Maybe a custom field for a function in <upstream-updater> could be
possible? WDYT?

-- 
Best regards,
Nicolas Graves

Re: Custom sha256 updaters ?

[Ludovic Courtès]

Hi,

Nicolas Graves <ngraves@ngraves.fr> skribis:

> Has there already been some discussion about custom hash updaters? I
> have written an import module for libreoffice, and we have access to the
> sha256 hash in for example
>
> https://download.documentfoundation.org/libreoffice/src/24.2.6/libreoffice-24.2.6.2.tar.xz.sha256
>
> which would make it trivial to update without having to download 267MiB
> of data twice.
>
> However, %method-updates doesn't seem to allow such a flexibility for
> now. Maybe a custom field for a function in <upstream-updater> could be
> possible? WDYT?

This hasn’t been discussed before, but allow me to be skeptical.  :-)

First because if you run ‘guix refresh -u’, surely you’ll want to
download the file (and note that it downloads it once, not twice,
because the file goes into the store).

Second because I think we want to encourage packagers to authenticate
source tarballs, and files containing lists of hashes are not helpful
for that.

Does that make sense?

Ludo’.

Re: Custom sha256 updaters ?

[Nicolas Graves]

On 2024-09-26 15:43, Ludovic Courtès wrote:

> Hi,
>
> Nicolas Graves <ngraves@ngraves.fr> skribis:
>
>> Has there already been some discussion about custom hash updaters? I
>> have written an import module for libreoffice, and we have access to the
>> sha256 hash in for example
>>
>> https://download.documentfoundation.org/libreoffice/src/24.2.6/libreoffice-24.2.6.2.tar.xz.sha256
>>
>> which would make it trivial to update without having to download 267MiB
>> of data twice.
>>
>> However, %method-updates doesn't seem to allow such a flexibility for
>> now. Maybe a custom field for a function in <upstream-updater> could be
>> possible? WDYT?
>
> This hasn’t been discussed before, but allow me to be skeptical.  :-)
>
> First because if you run ‘guix refresh -u’, surely you’ll want to
> download the file (and note that it downloads it once, not twice,
> because the file goes into the store).

That's true. For packages without a refresh method, most of the time
I download twice though.

> Second because I think we want to encourage packagers to authenticate
> source tarballs, and files containing lists of hashes are not helpful
> for that.

I was not asking for files containing lists of hashes but rather a
function field in updaters that would be able to quickly output the
hash. In this case, it could simply go read that .sha256 file, convert
to base32, and we have the hash.

I guess it's actually more useful when creating packages rather than
refreshing them indeed. I did something like that in a nonguix PR and it
helped a lot to generate definitions based on hashes online rather than
fetching 15*40 Mo twice (this time twice ;)). I've forgotten I've used
that more for creation than refreshing.  And while creating packages,
the cache is not always the store, hence the twice too.

>
> Does that make sense?

Yes, let's drop that and I'll just remember that this might sometimes be
useful but importer-specific.

-- 
Best regards,
Nicolas Graves