On Sun, 06 Oct 2024 at 10:02:56 +0200, Simon Josefsson wrote:
> Otto Kekäläinen <o...@debian.org> writes:
> > git-buildpackage supports dual import from both upstream git and
> > tarball to maximize supply chain auditability.
>
> That setup sounds nice! What is your workflow to import a new upstream
> release?
The GNOME team does this too. If the upstream git repo has "nice" tag names
and the tarball doesn't need repacking (e.g. src:glib2.0), the import
workflow is almost the same as if you were only using tarballs:
# once per checkout
# ("gbp clone --add-upstream-vcs" will do this for you automatically if
# your debian/upstream/metadata lists a Repository)
git remote add upstreamvcs https://...
# once per new upstream release
git fetch upstreamvcs
uscan --download
gbp import-orig .../glib2.0_*.tar.*
The necessary glue to set this up is that `debian/gbp.conf` has
"[import-orig] upstream-vcs-tag = %(version%~%.)s" or similar, to tell
git-buildpackage how to map a tarball version number to a tag. See dbus and
flatpak for examples of packages where the tag name has a prefix.
If the upstream tarball is repacked, for example to include inconveniently
large generated files (like GTK's HTML documentation) or vendored
convenience copies whose copyright status we would prefer not to have to
document, then you need to use something like
gbp import-orig --upstream-vcs-tag=4.16.3 .../gtk4_4.16.3+ds.orig.tar.xz
to compensate for that: I don't think git-buildpackage supports removing
an arbitrary suffix like +ds from the version number to get the tag name.
smcv
