[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Preservation of Guix report 2022-01-16
From: |
Ludovic Courtès |
Subject: |
Re: Preservation of Guix report 2022-01-16 |
Date: |
Mon, 24 Jan 2022 16:17:26 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) |
Hi,
zimoun <zimon.toutoune@gmail.com> skribis:
>> The more we make progress, the more it seems we won’t be able to avoid
>> storing multiple hashes.
>
> Yes, it appears to me unavoidable. The question is where store such
> hashes? At the origin level? At the package level via ’properties’?
> Using an external service? As Disarchive database? Other?
I was thinking <origin> could accept several hashes.
> From my point of view, the bridge between all the hashes should be done
> by SWH itself. They promote their ’swhid’ which is far less common than
> Git hashes, for instance. It would make sense, at least to me, that
> they would provide various maps using different keys. They already
> somehow provide the map Git+Sha1 to swid, they could also provide
> NAR+Sha256 to swhid and maybe other serializers checksum to swhid. The
> world existed before swhid. ;-)
In principle, sure, it would be nice if SWH could map from one hash
flavor to another.
In practice, I can understand why they wouldn’t want to compute
nar/sha256 or some other underground flavor for all the archived source.
I think we have to do something on our side. We could “upgrade”
<origin>, ‘guix-daemon’, and ‘guix publish’ so they can usefully handle
multiple hashes. That’d be a long-term effort.
Now, an external “hash mapping service” has its appeal: it could be put
to work right away. Tricky!
Ludo’.