Otto Kekäläinen writes ("Re: Include git commit id and git tree id in *.changes
files when uploading?"):
> Your response "you might not want to work with the
> maintainer-specific mess that Salsa is" to this assumes only the
> Debian Developer / Maintainer context which I didn't write anything
> about in my suggestion. There are a lot of companies that use Debian
> that have their additional internal or 3rd party repositories etc.
> Having a generic metadata field to track the git tag object and tree
> ids and tooling to populate those fields (e.g. dpkg-buildpackage)
> would help anyone anywhere audit what version of source code was
> announced as being used to build something, and then the auditing
> tools can incorporate that into their analysis to make pinpointing
> what stage introduced inconsistencies faster.
I agree that one ought to track what source code went into one's
binaries. But, anyone who doesn't need to provide .dscs for
compatibility reasons (ie, most of the people you are describing)
ought to work completely in git.
If everything is built automatically from git [1], this is easily done
starting with the version number: that tells you the tag name which
was used by your build robot, and you can find the tag in your git
server.
So in this case there is no benefit to any additional git tracking
metadaata in .changes files.
> [Adrian Bunk:]
> > If you want to actually be able to use that for audit purposes, you
> > might not want to work with the maintainer-specific mess that Salsa is.
>
> Gunnar already posted a good reply, but let me add that there are a
> lot of packages on Salsa that are well maintained and where reading
> and verifying changes is easy. For the packages that have
Sadly, "well-maintained" by current (legacy) Debian standards does not
mean that the .dsc in Debian even corresponds to upstream git, let
alone that it is easy to automatically verify that correspondence.
There are two importaant reasons.
Firstly, it is still common Debian practice to import into git
upstream "source tarballs" (which are almost always actually
intermediate build products, and often unreproducible). Indeed not
importing tarballs is controversial in Debian even though doing so has
been obsolete, hazaardous, and bizarre to outsiders, for many years.
Secondly, you don't know whether the git tree is supposed to be
patches applied, patches unapplied, or bare debian (or something even
weirder). You can guess of course, which is kind of OK for auditing,
but I don't think it counts as a definitive determination. dgit and
tag2upload record the necessary information in the signed git tags.
Finally:
> Yes, using tag2upload will prevent git and archive contents from
> diverging. Hopefully tag2upload also adds support for upstream tags
> and pristine-tar so signed tags and detached signatures can be
> uploaded to Debian (#1110269, #1106071),
Note that tag2upload doesn't make anything worse, with respect to
upstream git tags.
Best practice for git-based packaging is to push those upstream tags
to Salsa, where they are retained on Debian infrastructure. It would
of course be better if the tags were deposited to the formal
append-only depository, and that's what #1110269 is about.
But nothing about adopting tag2upload makes this situation any worse.
Indeed, it makes it better, because a tag2upload DEP-14 please-upload
tag contains the git objectid of the upstream tag. So with tag2upload
you can *more easily* trace things back to the signed upstream tag.
That ticket is just about our desire to make it even easier, by
avoiding the need to find the actual tag object on another Debian
server.
Ian.
[1]
For a worked example of how to be a Debian downstream and never deal
with source packages, you could do worse than Matthew Vernon's talk
about Wikimedia's approach, at Debconf 25:
https://debconf25.debconf.org/talks/119-automating-downstream-debian-package-builds-and-updates-in-ci/
https://salsa.debian.org/debconf-team/public/share/debconf25/-/blob/main/slides/119-automating-downstream-debian-package-builds-and-updates-in-ci/debconf_2025.pdf?ref_type=heads
This is (of course) based on dgit, notably the usage modes described
in dgit-user(7):
https://manpages.debian.org/testing/dgit/dgit-user.7.en.html
--
Ian Jackson <[email protected]> These opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
