[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Include git commit id and git tree id in *.changes files when uploading?



Hello Adrian,

Adrian Bunk dijo [Thu, Dec 18, 2025 at 10:56:42AM +0200]:
> tag2upload and dgit already do this.
...
Are you aware of any attempts to integrate this into dpkg-buildpackage
toolchain so systems that build .deb packages can have that metadata
field universally and not just via official Debian uploads via
tag2upload?

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.

Only debian/ or complete sources?
debian/patches/ or patches applied?
One git repository per package, or 1k packages in one git repository?
The contents of a git tag/commit does sometimes not match the
contents of the package in the archive with the matching version.
And a git repository might disappear, or the commit might disappear,
or the commit was never pushed anywhere.

The points you mention are all valid. However, I support Otto's idea here —
Git repoistories might disappear, or their history might be rewritten. It
_most often_, however, does not happen — sharing the specific commit from
which a given tree was built costs us _very_ little, and can provide
important information for many use cases.

The proper solution would be if we had the git trees in the archive,
in a modern setup where the buildds are integrated in the git hosting
runner infrastructure so that the git CI tests the actual packages.

But until then using tag2upload for your packages might be the best
option for that purpose.

tag2upload ensures that what is in the archive matches what is in git,
and it has a defined interface for going backwards for audit purposes.

Right, and I completely also support tag2upload as one of the most
important steps forward in Debian usability and modernization! However, if
the commit information is added to *.changes as Otto suggests, nobody loses
anything, and maintainers (and all of their packages' users!) not yet ready
to shift to this new scheme can start benefitting from said information.

   – Gunnar.

Attachment: signature.asc
Description: PGP signature


Reply to: