Re: On raw strings in <origin> commit field

[zimoun]

Hi Mark,

On Wed, 29 Dec 2021 at 20:13, Mark H Weaver <mhw@netris.org> wrote:

> Guix packages that refer to git _tags_ may cease to be reproducible in
> the future if upstream mutates or removes those tags, and it's simply
> not feasible to transform our SHA256 hashes (of the NAR-encoded source
> checkout) into something that we can use to fetch the archived source
> from SWH.  There's simply no hope to make that work, unless we can
> convince SWH to maintain a secondary index of their content based on
> NAR-encoded source trees, which seems unlikely.

Yes, that’s the core point. :-)

Basically, url+tag can work with the SWH API.  But SWH stores
snapshots so it is not always straightforward.


> On the other hand, if we refer to git _commit hashes_, then it *is*
> feasible for us to fetch the archived source from SWH, regardless of
> what upstream has done to its tags in the meantime.

Well, IMHO, the main point of the story is how to content-address, i.e.,
using which method.

SWH promotes their own encoding named ’swhid’ (basically, it looks
similar to Git commit).  Many other address types are around.

It had been discussed to maintain this secondary index via a Disarchive
database – potentially bridging from our SHA-256 to other addressing
hash.  One issue is that the package definition is not self consistent
and requires this external service.  On the other hand, we cannot
predict the future and who could tell which content-address systems will
be still there?  ;-)

This content-address is not an easy topic. :-)


Cheers,
simon