[bug#43442] [PATCH] Fixes init of #42162: gforge.inria.fr down Dec. 2020

[Timothy Sample <samplet@ngyro.com>]

Hello,

Ludovic Courtès <ludovic.courtes@inria.fr> writes:

> This whole hack looks like a dead end.
>
> It would be ideal if SWH would compute nar hashes, as you proposed:
>
>   https://gitlab.softwareheritage.org/swh/meta/-/issues/4538
>
> As a stopgap, I wonder if we could use “double hashing” on our side, but
> only for svn: we’d store both the nar sha256 as we currently do, plus
> the swhid.  It still seems to me that it’d be hard to scale and to
> maintain that over time, even if it’s limited to svn.  Plus, there’d
> still be the problem of ‘svn-multi-fetch’, which is what most TeX Live
> packages use.
>
> Thoughts?

Not too many, but I do have more bad news.  Apologies if this is already
known, but I’m just getting up to speed with how SWH handles Subversion
(for coverage checking) and thought this seemed pretty significant.

I was starting with doing a simple check for the “easy” Subversion
repositories.  That is, no externals (‘recursive?’) and no
‘svn-multi-fetch’ [1].  I immediately hit a problem.  Guix hashes the
export of the repository with the keywords processed, while SWH hashes
it with unprocessed keywords.

For example, take ‘libsmpeg’.  It has a file called “mkinstalldirs”,
which has a keyword in it: “$Id$”.  The SWH loader hashes this as

    $Id$

while we hash it as

    $Id: mkinstalldirs 9 1999-10-21 15:55:01Z hercules $

This is not a big issue in terms of coverage checking, but it will be an
issue for automatic recovery.  Even if you know the exact SWH directory
ID, you won’t get a directory that satisfies the daemon’s hash check.  I
have no idea how hard it is to process the keywords with only data from
SWH.  In this case, you would have to walk revisions to find the last
time “mkinstalldirs” was modified, and then format its metadata.
However, I assume the Subversion properties are gone, so there might be
edge cases like a file with “$Id$” (or whatever) that Subversion
wouldn’t processes.

Again, apologies if this is old news.  Actually apologies either way,
’cause this is a bit of a downer!


-- Tim

[1] More precisely, I was going to process recursive ‘svn-fetch’ origins
because a lot of them are needlessly marked as recursive.  In some
(many?) cases, the repositories don’t actually have external references,
so the flag does nothing.  I was only going to skip the ones where it
makes a difference.