Hi all,
I agree with Jacob that config.guess and config.sub are intended to be
drop-in updates, and that adding support for a new platform without
changing a package’s code is a real strength of GNU config.
There is a separate issue, though: downstream packagers need a stable,
identifiable source archive.
A release can provide that without implying a major change or breaking
compatibility: it gives packagers a fixed artifact, an official download
location, and a checksum they can record and verify.
For example, Conan Center recipes specify download URLs and a SHA-256
checksum for each source version.
A GnuTLS recipe lists several mirrors for the same archive and one checksum:
```
sources:
"3.8.7":
url:
- "https://www.gnupg.org/ftp/gcrypt/gnutls/v3.8/gnutls-3.8.7.tar.xz";
-
"http://www.ring.gr.jp/pub/net/gnupg/gnutls/v3.8/gnutls-3.8.7.tar.xz";
-
"https://www.mirrorservice.org/sites/ftp.gnupg.org/gcrypt/gnutls/v3.8/gnutls-3.8.7.tar.xz";
sha256:
"fe302f2b6ad5a564bcb3678eb61616413ed5277aaf8e7bf7cdb9a95a18d9f477"
```
GNU config illustrates why this matters.
Conan Center Index has a package reference for GNU config named
gnu-config/cci.20210814.
Here, cci stands for Conan Center Index; this is a Conan package version
identifying a dated snapshot, not an official upstream GNU config release.
Since Savannah’s cgit-generated snapshot downloads are disabled and no
official release archives are available, downstream packagers currently
lack a supported, canonical archive to reference.
A checksum lets a package manager verify that the downloaded file
matches the expected archive, regardless of which mirror supplied it.
This supports reproducible builds and helps detect accidental changes or
corrupted downloads.
It is not a substitute for a signature or other provenance checks, but
it is an important part of the distribution workflow.
Publishing official source archives in Savannah’s releases area (whether
as periodic dated snapshots, major.minor releases, or a latest pointer
to an immutable, versioned archive, whichever cadence the maintainers
consider most appropriate) would give downstream consumers a supported
download location and stable, checksum-verifiable artifacts, while
preserving the rolling-release and drop-in compatibility model Jacob
described.
Best,
Ariel
