[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Simon Tournier
Subject: [bug#43442] [PATCH] Fixes init of #42162: down Dec. 2020
Date: Mon, 03 Apr 2023 15:34:59 +0200


On lun., 20 mars 2023 at 15:09, Ludovic Courtès <> 

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

As proposed, somehow, in [1], I think we have nothing to loose with
optionally “double hashing” (or even triple or more).  I do not
understand your concerns in [1] and I will discuss overthere. :-)

About ’svn-multi-fetch’ and TeX, what is at our advantage is that most
TeX Live packages use ’svn-multi-fetch’ via ’simple-texlive-package’
relying on ’texlive-origin’.  And from official TeX documentation [2],
Subversion is not the recommended access, instead they suggest to rely
on ’rsync’.  Moreover, some Git mirror is available.

Therefore, about TeX we could ask if relying on Subversion is still the
“good” way and maybe we could switch to something else as url-fetch or
git-fetch.  Hum?!  Not convinced by my proposal here. :-)

Well, IMHO, there is 2 issues: one about using SWH as fallback for
packages using svn-fetch and another one about TeX Live packages.  It
could be nice to solve them both at once but maybe we should start now one
foot, now the other.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]