Re: Bug#1111127: ITP: golang-go.yaml-yaml-v3 -- YAML Support for the Go Language
> > I think we should have *both* upstream git history and pristine-tar to
> > ensure the tarball has the same shasum no matter who produces it. It
> > happens automatically if you have these lines in gbp.conf:
>
> What's the point of checking the tarball checksum? I mean, of course it
> has value when done by itself. But does it still have value when the
> tarball is just a temporary artifact generated by an audited Git
> history?
Uploads to the Debian archive, and what is stored in the Debian
archive is still tarballs. Same applies for Ubuntu, and various
tooling we have around uploads. Running dput to ftp-master, security,
mentors, Launchpad etc will push tarballs and those checksums better
match or uploads get rejected or the archive ends up having two
versions of the same upstream tarball with different checksums.
I use pristine-tar in all my packages, but occasionally on some
packages I don't or somebody else does not and for example I got this
in April on a Launchpad upload:
> Rejected:
> File usql_0.19.19.orig.tar.gz already exists in PPA for Otto Kekäläinen, but uploaded version has different contents. See more information about this error in https://help.launchpad.net/Packaging/UploadErrors.
> Files specified in DSC are broken or missing, skipping package unpack verification.
> usql (0.19.19-1~bpo25.04.1~1744533524.754fef8+import.0.19.19) plucky; urgency=medium
> Also, by not having to work with tarballs, you not only stop needing the
> pristine-tar branch, but you also no longer need the upstream/latest
> branch. Why? Because you're not actually building the upstream branch
> yourself via gbp imports, but you're just branching off upstream tags
> (which still carry commit history, of course). This means that in Salsa,
> you can finally just store one single branch!
This is true. But it includes a very large assumption that all
upstreams use git and all imports can be based on git tags. Even for
upstreams that use git, some of them still publish tarballs that have
for example documentation added that is from a separate repository, or
large binary test files removed as the project does not intend to ship
them to end users. For the time being, a tarball with files is the
only common denominator across all upstream software.
By using both of these..
pristine-tar = True
upstream-vcs-tag = v%(version%~%-)s
...we get a nice audit trail that allows us to see if an upstream has
custom tarball contents, and how those exactly differ from what was in
git. This can be used to scan for how many upstreams have custom
tarball contents which can help a long-term drive to get upstreams to
have signed git tags as their official announcement method.
Reply to: