Re: What's the state of (guix build download-nar)?

[Christopher Baines <mail@cbaines.net>]

[-- Attachment #1: Type: text/plain, Size: 1810 bytes --]


Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

> Hi,
>
> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Hi Chris!
>>
>> Christopher Baines <mail@cbaines.net> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]