On 2026-02-11 14:09:12 +0000 (+0000), Simon McVittie wrote: [...]
upstream packages that expect/require that their package is either being built from git (with ./.git and history available for `git describe`, which our buildds notably don't have) or from a tarball (with extra files like ./.tarball-version to compensate for not having git history) but not some middle ground between those.
[...]
I collaborate on release automation work upstream for a community that produces very many applications and libraries packaged in Debian which fall into this particular category. We do push signed Git tags and we publish signed tarballs built from these tagged states, but our tarballs incorporate content from Git metadata that is not present in the raw working tree that's checked into the repository.
A non-exhaustive list includes:* setting internal version data for the software based on the name of the corresponding tag in Git
* generating AUTHORS files referred to in some licenses* associating loose release notes with the correct versions based on the subsequent Git tag after the Git commits that added them
* generating changelogs * release process information fetched in Git notes objectsAs this sort of information is already present in the Git repository in one form or another, we intentionally avoid checking duplicate copies of it into the working tree. Doing so is racy in some cases, or risks getting out of sync, as we're machine-coordinating and orchestrating asynchronous development between thousands of contributors, so a "release" tag is essentially a snapshot in time to which we can refer to a known state of the repository by a convenient shorthand version number.
Upstream we consider our Git *repositories* to be the "preferred form for modification" and not the Git *working trees* alone. The signed tarballs we publish are a compromise for downstream packaging workflows that are unable to accommodate full Git repositories (shallow clones are insufficient/problematic for most of the metadata we rely on). I have to assume we're not the only upstream community that's adopted this sort of approach, and I don't know what other sort of compromise we could make without giving up our goal of not duplicating Git metadata into the working tree.
-- Jeremy Stanley
signature.asc
Description: PGP signature
