* Custom sha256 updaters ? @ 2024-09-20 23:20 Nicolas Graves 2024-09-26 13:43 ` Ludovic Courtès 0 siblings, 1 reply; 3+ messages in thread From: Nicolas Graves @ 2024-09-20 23:20 UTC (permalink / raw) To: guix-devel 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Custom sha256 updaters ? 2024-09-20 23:20 Custom sha256 updaters ? Nicolas Graves @ 2024-09-26 13:43 ` Ludovic Courtès 2024-09-26 14:37 ` Nicolas Graves 0 siblings, 1 reply; 3+ messages in thread From: Ludovic Courtès @ 2024-09-26 13:43 UTC (permalink / raw) To: Nicolas Graves; +Cc: guix-devel 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’. ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Custom sha256 updaters ? 2024-09-26 13:43 ` Ludovic Courtès @ 2024-09-26 14:37 ` Nicolas Graves 0 siblings, 0 replies; 3+ messages in thread From: Nicolas Graves @ 2024-09-26 14:37 UTC (permalink / raw) To: Ludovic Courtès; +Cc: guix-devel 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2024-09-26 19:57 UTC | newest] Thread overview: 3+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2024-09-20 23:20 Custom sha256 updaters ? Nicolas Graves 2024-09-26 13:43 ` Ludovic Courtès 2024-09-26 14:37 ` Nicolas Graves
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/guix.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.