Re: Preservation of Guix report 2022-01-16

["Ludovic Courtès" <ludo@gnu.org>]

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’.