Maxim Cournoyer writes: > Hi, > > Ludovic Courtès writes: > >> Hi Chris! >> >> Christopher Baines skribis: >> >>> I guess this raises two things in my mind. I'm not sure this'll work >>> well given the not so recent changes to ci.guix.gnu.org. This module >>> looks to rely on gzipped or uncompressed nars. I'm not sure uncompressed >>> nars are available, and gzipped ones are no longer available. >>> >>> The second question is around the relation to bordeaux.guix.gnu.org, is >>> it worth trying to support fetching nars from bordeaux.guix.gnu.org >>> here, and what would be the best way of doing that? It wouldn't be too >>> hard to add support for decomressed nars I think if that's a good >>> approach? >> >> Uh, that module needs love indeed. >> >> Currently it’s used by some of the (guix VCS-download) modules. I think >> we should just update to (1) use lzip instead of gzip, and (2) have it >> check ci.guix.gnu.org + bordeaux.guix.gnu.org. > > How about using zstd? I'm proposing it instead of lzip, because long > term, I think we want to reduce the size of our storage requirements and > offer a single compression type for our NARs, which zstd would be ideal > (it's faster and compresses close enough to lzip). I haven't looked at the code, but I don't know of a specific reason why multiple compression options can't be supported here. Anyway, at least for bordeaux.guix.gnu.org (which already just stores a single compression for nars), supporting lzip is a must as that's the compression used. I'm not sure there's a good reason to change that, although that does depend on how offering some zstd compressed nars plays out in terms of performance for users. Thanks, Chris