On Thu, Feb 12, 2026 at 12:25:23PM +0100, Marc Haber wrote: >On Thu, Feb 12, 2026 at 01:26:52AM +0000, Colin Watson wrote: >>Well, for my own packages I insist on including upstream git >>history, so this certainly wasn't my choice, and it was before my >>time on the DPT. > >Whlie we are talking about this topic: Many packages have >un-autoconfed sources in their git master, then tag a release, run >autoreconf (optionally setting a version number) on the tree and >packagee that up as their release tarball. Thus, we have the release >tag pointing to different content than what is in the release tarball. > >While I do understand that this is the exact workflow that allowed the >xz-attack to happen, this is still the reality especially for pakages >on "Zugschlus' scrap shelf". > >How would I: >- convert such a package to have the upstream git history in salsa's >main branch >- still be able to do an upload with upstream's signed origtargz >- probably even have upstream git history in git log of debian/latest?
Using "gbp import-orig --upstream-vcs-tag" [1] for the next new release you import from upstream takes care of this. If you use that, then your git history will look something like this. I've used ASCII art similar to tig's main view, which I hope will make sense even to people who aren't regular users of tig: . [debian/latest] Update upstream source from tag 'upstream/1.1.0' |\ | . [upstream/latest] <upstream/1.1.0> New upstream version 1.1.0 | |\ | | . <1.1.0> Prepare 1.1.0 release | | | | | . [more upstream commits here] | | | . | | Update upstream source from tag 'upstream/1.0.0' |\| | | . | <upstream/1.0.0> New upstream version 1.0.0 ... and so on. That is, the actual upstream tag will be an additional parent of the commit on your "upstream/latest" (or whatever) branch. The commits that are "directly" on your upstream/latest branch will have trees that are identical to the unpacked release tarballs. In the example above, the diff between the commits I've identified as <1.1.0> and <upstream/1.1.0> should be equivalent to the effect of running "autoreconf" or "make dist" or whatever upstream do to make their release tarballs. If you want to look at a real example of what this looks like, https://www.eyrie.org/~eagle/notes/debian/git.html says that Russ uses this approach for his packages, so I picked one at random and indeed https://salsa.debian.org/rra/docknot seems to match this. [1] "git-dpm import-new-upstream --parent" does the same kind of thing, but git-dpm wants you to buy into its approach to patch management as well, so that's probably only appropriate if you're already using it. I happen to prefer it, but it's not to everyone's taste. >I guess this would need to fork off upstream's release tags, add the >diff to the release tarball every time, set my own "upstream" release >tag, and merge that into debian/latest. Sadly, rebasing debian/latest >on my own "upstream" release tag wouldn't work since that'd rewrite >debian/latest history every time a new upstream release comes, right? This workflow merges rather than rebasing, indeed. But "gbp import-orig" handles the juggling of branches for you. >And uscan probably doesn't suppoer that either, right? You can use the above approach together with uscan to fetch the tarballs, but I would drive it from gbp - that is, use something like "gbp import-orig --pristine-tar --uscan --upstream-vcs-tag=whatever". >I think that most of the people promoting building debian packages >from upstream git expect upsream to have the release tarballs and the >release tag have the identical contents, if there is a release tarball >in the first place. In my set of packages, this is a rare case. I may be one of the people you're referring to, but I certainly don't have that expectation; I too have quite a few packages where upstream release tag != upstream release tarball. -- Colin Watson (he/him) [[email protected]]
