On 2021-08-25 16:11:37 +0200 (+0200), Thomas Goirand wrote: [...] > I wrote this many times, but I don't see why we should use any "upstream > tarball" when the Git repository itself contains the tarball with: > > git archive --prefix=$(DEBPKGNAME)-$(VERSION)/ $(GIT_TAG) \ > | xz >../$(DEBPKGNAME)_$(VERSION).orig.tar.xz > > (which leads to a .xz, which is nicer) This is a very absolutist statement. As pointed out in prior discussions, not everything which makes it into an upstream's release tarball is necessarily tracked in revision control. And for things which are tracked in revision control, they may sometimes need to be extracted from the revision control metadata rather than kept within the worktree, so would not be included by naive git archive output. You could perform the necessary steps to extract/assemble this data at package build time, but may need a copy of the actual upstream Git repository on hand in order to do so. Some of these extracted files may even be referenced in copyrights (e.g. an AUTHORS file), with reliance on the worktree contents alone leading to a legally undistributable downstream copy. > Not only then, only only has to merge the upstream tag in the Debian > branch to get the new release, but on top, no need to "gbp import" or > "pristine-tar commit", and a single packaging branch becomes enough. [...] Yes, if you have the upstream Git repository, things like revision history can be accessed when generating the source package. However, if upstream already supplies signed source release tarballs with this extracted for you, and guarantees through testing that they don't omit files from the worktree in their official tarballs, redoing all that at source package build time does seem marginally obsessive (though I suppose that's fine so long as you actually remember to do it). -- Jeremy Stanley
Attachment:
signature.asc
Description: PGP signature