On Mon, 12 Jan 2026 at 20:01:17 +0100, Lucas Nussbaum wrote:
It would probably be a better practice if the upstream developer
gpg-signed the auto-generated tarball.
... except in the cases where the auto-generated tarball is not what the
upstream developer wants to be releasing, but Github won't allow them to
turn it off.
Some typical examples of reasons why a git-using upstream wants to
release their own canonical source artifact that is not a `git archive`:
- they want generated files to be added, especially for Autotools
projects
- or the opposite: they want to omit something that is in upstream git
but less useful downstream, like a large test dataset, or non-Free
files, or an alternative build system that is not relevant on Unix
- or they want some version marker to be added, like git-version-gen's
.tarball-version, SDL's REVISION.txt or anything analogous, so that the
tarball is self-identifying without .git and still knows its own version
number (possibly without needing manual edit/commit at release time)
- or they want submodules to be converted into subtrees, or some other
mechanism for adding (or removing) subprojects
I'm sure some of those are non-ideal, but the reality is that there are
upstreams who do things we consider to be non-ideal and will not be
persuaded otherwise, and often we want to package their software anyway.
And, when upstreams do release a source artifact that is not a `git
archive`, the best-practice documented in the Developers' Reference
demands that we use it. I realise that Ian considers the advice in
devref to be wrong, and will presumably dismiss me as incompetent or
unethical for following it; but others in the project will consider it
to be a failure to cooperate if I *don't* obey the advice in devref, so
I'm sorry but whatever happens, *someone* is going to have to be
disappointed.
smcv
