Hi! First of all thanks to Ian and Andrea for working on this tirelessly since DebConf. For my packages having support for pristine-tar and using real original tarballs is important and I am looking forward to see https://salsa.debian.org/dgit-team/dgit/-/merge_requests/264 finished.
I have one question about the design: How will this behave with repackaged sources? For example in Godot we use d/copyright Files-Excluded to tell uscan to repackage the upstream tarball, with a resulting pristine-tar branch commit and filenames like this: commit 3aefb8ae3866d43ca1ecd9e58872c2b1cf5c7f39 (HEAD -> pristine-tar) Author: Travis Wrightsman <[email protected]> Date: Wed Jul 30 21:28:23 2025 +0200 pristine-tar data for godot_4.4.1+ds.orig.tar.xz diff --git a/godot_4.4.1+ds.orig.tar.xz.delta b/godot_4.4.1+ds.orig.tar.xz.delta new file mode 100644 index 00000000000..e888d17a93b Binary files /dev/null and b/godot_4.4.1+ds.orig.tar.xz.delta differ diff --git a/godot_4.4.1+ds.orig.tar.xz.id b/godot_4.4.1+ds.orig.tar.xz.id new file mode 100644 index 00000000000..5ddcd1b0750 --- /dev/null +++ b/godot_4.4.1+ds.orig.tar.xz.id @@ -0,0 +1 @@ +2fddcc20d38b7f802ff624d597436262e28a1058 If is of course debatable if pristine-tar + repackaging makes sense anymore, as we intentionally break the supply-chain "seal" and the upstream tarball signature can't be used to verify the tarball in Debian anymore. I would also accept the outcome that in case of repacking, tag2upload would opt out from using pristine-tar. But some could argue that it should be used anyway for consistency due to how uscan and git-buildpackage are expected to have a certain branch layout and contents, and pristine-tar would at least ensure that people working on the package will have the same source (before upload, when getting sources from git is still relevant). What are your thoughts on repackaging?
