Re: Debian choice of upstream tarballs for packaging
On Wed, Aug 25, 2021 at 04:11:37PM +0200, Thomas Goirand wrote:
>
> It's been *years* since I encounter a PyPi package that doesn't have a
> Git repo as its homepage (and unfortunately, 99% on Github).
>
> 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)
Well, if we don't use an "upstream tarball", we do need to keep our
own private archive the Git repository. After all, there is no
guaranteee that the upstream git repo might disappear in the future.
Simon's proposal that use use a tarball of the bare git repo
containing all of the git objects needed leading up to the signed tag
works, but isn't necessarily the most efficient over time, since we
would be keeping multiple copies of redundant git repos in
snapshots.debian.org, or across multiple Debian versions in our ftp
archives. But it at least guarantees if we will continue to have
access to the source even if the upstream git repo goes *poof*.
> 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.
>
> I very much wish this packaging workflow gained more traction, and the
> pristine-tar abomination dies...
Sure, but it implies that the git repos on salsa and/or dgit have to
become our official source of record for the purposes of GPL
compliance. Which means we need to be a lot more careful about ever
allowing those git trees from being deleted or rewritten, even if the
goal is to remove files that might be found to be problematic
copyright licensing perspective.
- Ted
Reply to: