Hi Otto!
On Sat Aug 16, 2025 at 9:29 PM CEST, Otto Kekäläinen wrote:
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 wouldn't say that I've worked tirelessly on this, but thanks :)
I have one question about the design: How will this behave with
repackaged sources?
I think it would behave exactly like non-repackaged origs. The
upstream/<num> tag would contain the repackaged code, and the
pristine-tar data would contain the usual binary diff. pristine-tar does
not "know" that the tarball was repackaged, and tag2upload doesn't care
either.
Hope it makes sense to you! If you have any doubt, just ask.
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?
Yeah, to me it doesn't make much sense. But I do use pristine-tar with
some packages with repacked sources, in some packages. I shouldn't, I'll
probably stop, but I'm currently doing so.
Bye :)
