On 2024-09-26 15:43, Ludovic Courtès wrote: > Hi, > > Nicolas Graves <ngra...@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
