Thanks Pirate Praveen for providing the first actual concrete case in
this thread where pristine-tar had some issue!
I noticed an interesting thing about this case:
± origtargz --download-only
pristine-tar: successfully generated
../node-cacache_17.0.3+~cs10.3.7.orig-npmcli-move-file.tar.gz
pristine-tar: successfully generated
../node-cacache_17.0.3+~cs10.3.7.orig-npmcli-fs.tar.gz
pristine-tar: successfully generated
../node-cacache_17.0.3+~cs10.3.7.orig-infer-owner.tar.gz
pristine-tar: successfully generated
../node-cacache_17.0.3+~cs10.3.7.orig-gar-promisify.tar.gz
pristine-tar: successfully generated
../node-cacache_17.0.3+~cs10.3.7.orig-fs-minipass.tar.gz
fatal: ambiguous argument
'60b4383b8c982ac64553f2754abaefe7ca7ebf79^{tree}': unknown revision or
path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
fatal: not a valid object name: 60b4383b8c982ac64553f2754abaefe7ca7ebf79^{tree}
tar: This does not look like a tar archive
tar: Exiting with failure status due to previous errors
pristine-tar: command failed: git archive --format=tar
60b4383b8c982ac64553f2754abaefe7ca7ebf79\^\{tree\} | (cd
'/tmp/pristine-tar.obWgetreHi' && tar x)
± git show 60b4383b8c982ac64553f2754abaefe7ca7ebf79
fatal: bad object 60b4383b8c982ac64553f2754abaefe7ca7ebf79
± git fetch origin 60b4383b8c982ac64553f2754abaefe7ca7ebf79
fatal: remote error: upload-pack: not our ref
60b4383b8c982ac64553f2754abaefe7ca7ebf79
fatal: the remote end hung up unexpectedly
± gbp export-orig --pristine-tar
gbp:info: Creating
/home/otto/debian/js-team/node-cacache_17.0.3+~cs10.3.7.orig.tar.gz
gbp:info: Creating
/home/otto/debian/js-team/node-cacache_17.0.3+~cs10.3.7.orig-fs-minipass.tar.gz
gbp:info: Creating
/home/otto/debian/js-team/node-cacache_17.0.3+~cs10.3.7.orig-infer-owner.tar.gz
gbp:info: Creating
/home/otto/debian/js-team/node-cacache_17.0.3+~cs10.3.7.orig-npmcli-move-file.tar.gz
gbp:info: Creating
/home/otto/debian/js-team/node-cacache_17.0.3+~cs10.3.7.orig-npmcli-fs.tar.gz
gbp:info: Creating
/home/otto/debian/js-team/node-cacache_17.0.3+~cs10.3.7.orig-gar-promisify.tar.gz
And then suddenly the git ref has emerged:
± git show a1567ff8077126b7aa8536b779e3e445ba367a49
tree a1567ff8077126b7aa8536b779e3e445ba367a49
.github/
LICENSE.md
README.md
index.js
package.json
test/
± gbp export-orig --pristine-tar
gbp:info: Creating
/home/otto/debian/js-team/node-cacache_17.0.3+~cs10.3.7.orig.tar.gz
gbp:info: Creating
/home/otto/debian/js-team/node-cacache_17.0.3+~cs10.3.7.orig-fs-minipass.tar.gz
gbp:info: Creating
/home/otto/debian/js-team/node-cacache_17.0.3+~cs10.3.7.orig-infer-owner.tar.gz
gbp:info: Creating
/home/otto/debian/js-team/node-cacache_17.0.3+~cs10.3.7.orig-npmcli-move-file.tar.gz
gbp:info: Creating
/home/otto/debian/js-team/node-cacache_17.0.3+~cs10.3.7.orig-npmcli-fs.tar.gz
gbp:info: Creating
/home/otto/debian/js-team/node-cacache_17.0.3+~cs10.3.7.orig-gar-promisify.tar.gz
Also comparing output with what I manually downloaded from
https://github.com/npm/cacache/releases/tag/v17.0.3
$ sha256sum v17.0.3.tar.gz node-cacache_17.0.3+~cs10.3.7.orig.tar.gz
2daa2c943a9cf316eef10eda6883ac967ca32cc28de9decef147ea42bdc34283 v17.0.3.tar.gz
2daa2c943a9cf316eef10eda6883ac967ca32cc28de9decef147ea42bdc34283
node-cacache_17.0.3+~cs10.3.7.orig.tar.gz
Not sure what happened here. However in the end pristine-tar worked,
and I was able to use it to verify the tarball. Longer notes in
https://pad.debian.net/p/node-cacache-pristine-tar.
There are however a lot of oddities in this package that makes it unusual
- You don't have 'pristine-tar = True' in debian/gbp.conf. You should
have it to enforce it is used and git pulled and git pushed
consistently.
- There is no README.source explaining what this '+~cs10.3.7' thing in
the version is. I assumed you had repackaged something, but then also
was surprised that it actuall was the same as upstream.
- This package consists of the main package and 5 components that are
all mangled together. Is that necessary? I am surpised such a complex
thing actually seems to work
In summary: nothing in this is an argument to stop using pristine-tar
in all packages. I think Theodore Ts'o also laid out pretty well all
the benefits of pristine-tar and why it was originally developed, and
those requirements and benefits still stand. Sure, we can in future
also have other ways to do this in a future debian package format 3.1,
but right now I warmly recommend people use 'pristine-tar = True' in
their gbp.confs.
