Hi,
On 2/18/25 00:21, Jeremy Stanley wrote:
Debian has, for legal and logistical reasons, decided that it cannot
distribute upstream Git repositories as its source packages, and
instead chooses to try to condense upstream's preferred form for
modification (back) into source tarballs.
If we "cannot", then it is not something we "choose".
We have several upstreams whose git repositories contain files that may
be legal for upstream to distribute, but that do not fulfill our,
stricter, requirements, or where we do not want to ship the files as
they are for technical reasons, such as when upstream is vendoring old
versions of libraries.
We have a toolchain that can handle file exclusions when importing
source archives from upstream, and these tools output a compressed
source tarball.
In theory, they could output a git bundle with the offending files
removed, but this would not be useful: simply removing the objects makes
it impossible to import the bundle, and changing the objects changes the
hashes, so neither can fulfill the role of "preferred form for
modification."
What I'd like to see at some point is "compressed bundle containing a
single commit or tag" as the orig archive. Verifying this against
upstream is a little harder than for upstream released tarballs (where I
can just check if the file in Debian is bitwise identical to the one
released and possibly signed by upstream), but that can be fixed with
appropriate tooling.
This would not work, however, for upstreams where we exclude files: for
this, we'd need to extend git to allow us to both create and import
incomplete bundles. That is a lot harder, but would be required for this
to be universally useful.
(there is also some correlation between "upstream's git does not contain
any unredistributable files or vendored dependencies" and "upstream
ships a usable source tarball", so precisely the cases where git is the
only upstream we have are the cases where that is least useful to us)
Simon
