Re: Debian choice of upstream tarballs for packaging
On 8/25/21 5:01 PM, Theodore Ts'o wrote:
> 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.
What I was saying is that you don't need to use the Github generated
tarballs, because likely they are also generated with git-archive, so
doing it yourself achieves the same thing. You do not need to even keep
the upstream branch, the only thing you need is to push the Git tags
from upstream (which by itself contains the whole thing...).
> 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*.
If pushing the upstream git tags to Salsa, you're safe, and the way we
do in the OpenStack team, we still generate and upload tarballs to the
Debian archive matching each tags.
>> 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
That's the thing with git: anyone working on the repository will hold a
local copy, which can act as a backup... :)
Thomas Goirand (zigo)
Reply to: