versioning TeXlive packages on CTAN

[Mojca Miklavec]

Hi,

I'm with Brook on this.

I'm pretty sure this is not feasible for the full CTAN, but it might
be doable in the scope of TeX Live packages alone.
TeX Live is already versioning the archived packages locally for
backups. It could just as easily fetch the versioned filenames
directly once it has read the package versions from the database.

We have very similar principle in MacPorts, and would face the exact
same problems (and the same solution would help us) ... if we actually
bothered packaging each individual package separately, which would be
a bit of a nightmare anyway. What our maintainer does is create his
own archive, upload it to his own server first, and then the files get
mirrored, see for example:
    http://distfiles.macports.org/texlive-basic/
but that's heavily suboptimal, as our bus factor of packaging TeX Live
is currently equal to one. Even if I would be enthusiastic in helping,
I feel it's too complex and cumbersome, so if that bus factor drops,
we might get similar delays in updates as when tetex was discontinued.

If talking about downstream packaging and adding versions to archives
(which I fully support), I wouldn't mind if the script which does the
daily updates would also create one versioned tarball with all the
packages from a collection (split into run / doc / src), ignoring
inter-package dependencies of course. Those could be put to a
different location if there's a space concern, but in any case it
would be really handy to also archive a few dozen such tarballs next
to "TeX Live 2020 archive" (on the historic FTP or wherever).

Looooooong time ago I made a prototype (but never took the time to
finish it) of the code which iterates through all subversion commits,
checks for changes in texlive database file ... and finally makes a
separate git repository for every single package from TeX Live and
tags versions for each package. It should basically create an
equivalent of archiving contents of individual packages as they change
over time. If pushing those repositories on GitHub, GitLab or any
other site (provided one wouldn't hit constraints), one could use the
existing mechanism to automatically create tarball for an arbitrary
version. That solution would hardly consume any more space than just
archiving a single copy of TeX Live, yet it would provide all historic
versions of tarballs (on demand) out of the box.

Mojca