On 2024-05-12 12:50, Bruno Haible wrote:
Your real goal, which is — AFAIU — to allow distros to discard part
or all of the tarball and to redo the packaging work done by the release
manager in a different way, would be better served with a
1) machine-readable file,
2) somewhere in or in the vicinity of the tarball.
Although that's a good goal to have (see below), it's reasonably
ambitious. For example, the tool lists we've been mentioning are
incomplete, partly due to indirect dependencies (no glibc?) and partly
not (no coreutils?) and it will be a pain to complete them (no firmware
IDs? no motherboard or CPU IDs? you get the picture...). So I suspect
that having an intermediate goal could be worthwhile.
In other words, if you really want to go this way — against the advice that
I gave you above —, better replace the two lines with:
This release is based on the inetutils git, available at
https://git.savannah.gnu.org/git/inetutils.git
commit 524d4b6934db12b9f43be410d2f201fdb40cfc97, also labelled v1.42.
This is good advice. It's similar to wording I use in announcements of
TZDB distributions (e.g.,
<https://mm.icann.org/pipermail/tz-announce/2024-February/000081.html>).
For what it's worth, those TZDB announcements have always intended to be
human readable but various downstream projects parse the text and grab
checksums and signatures and whatnot. The pull of automation is indeed
strong, and your advice about going for automation is good.
