Tagging releases for source transparency and downstream packaging

[dvzrv]

Hi @PiotrDabkowski

I am currently revisiting the package for this project on Arch Linux and I noticed that there are no tags in this repository. I see that there are related tickets such as #31 and #258 which have all been left unanswered.

From a downstream perspective this is very problematic for several reasons:

• sources can not be sufficiently audited (sdist tarballs on PyPI are not the same as an auto-generated tarball)
• sdist tarballs on PyPI are created in unknown environments (e.g. developer machines, CI) and may contain unrelated artifacts
• commits from which to build have to be "guessed" from the changes

Only recently we have seen a long-planned attempt at placing a backdoor into many Linux distributions via the xz upstream. This attempt was in large parts made possible by a custom tarball (the PyPI sdist tarball is such a custom tarball as well).

On Arch Linux we have chosen to switch to upstream provided sources (VCS objects or auto-generated tarballs) for the Python ecosystem, because the sdist format is ill-defined and often lacks files that we need (tests, licenses - related: #172 , etc.): https://rfc.archlinux.page/0020-sources-for-python-packaging/

Please add a tag for 0.74 (2e017b8) and going forward use tags, so that downstreams can rely on transparent sources for this upstream.

Thanks 🙏

[cybaol]

@dvzrv
The upstream is inactive for a long time. So I think a temporary solution is using git commit like https://gitlab.archlinux.org/archlinux/packaging/packages/accerciser/-/blob/main/PKGBUILD?ref_type=heads

[dvzrv]

@cybaol I'm aware, but that doesn't mean this can't / won't change in the future. :)

So I think a temporary solution is using git commit like

That doesn't really work the same way in the case of this repository, as not a single tag exists. However, we can have a custom pkgver() function of course, that hardcodes stuff... but this is even more pain to package (hence this ticket).

Seeing how this entire project isn't compatible with Python 3.12 (#317), we may as well drop it and anything that relies on it from the repositories though.