Ben Harris writes ("Bug#1126123: git-deborig: should maybe use gzip -n
--rsyncable -9"):
> This means that it produces a tarball that's different from what uscan
> produces. uscan (from devscripts 2.26.5) runs gzip like this:
>
> execve("/usr/bin/gzip", ["gzip", "-n", "--rsyncable", "-9"], ...
>
> This means that 1.0-with-diff packages with orig tarballs made using
> git-deborig get mismatches from orig-check:
>
> https://orig-check.debian.net/orig-check/result/802f4ed0a9a76790799ff4484c1dbf04bda6c28357cd22d4130c40d9349883e7
>
> I've checked two other tools that produce gzipped orig tarballs for
> Debian source packages, and found:
>
> dpkg-source -sU -b (dpkg-dev 1.23.4)
> execve("/usr/bin/gzip", ["gzip", "-n", "--rsyncable", "-9"], ...
>
> gbp export-orig (git-buildpackage 0.9.39)
> execve("/usr/bin/gzip", ["gzip", "-n", "-c"],
>
> So there seems to be a fairly even split. I think that the options used
> by dpkg-source are probably better, and arguably it's also the canonical
> implementation. So I think it would be a good idea for git-deborig to
> adopt the same gzip settings as dpkg-source and uscan.
>
> This would make it more likely that tarballs produced by git-deborig would
> match those produced by uscan.
Another consideration is that we might want to make them match what
you get from git forges' tarball download features.
Ian.
--
Ian Jackson <[email protected]> These opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
