Hi again!I tried to add to the tag2upload.5 manpage the pristine-tar handling design outlined in our discussions, which is inline below. Still, I have a few questions:
What should we do with that upstream commit metadata? pristine-tar does not need that, since it'll generate the tarball from the git tree id stored in source_version.orig.tar.id. Still, we might want to make sure that the pristine-tar tree corresponds to the one of the upstream commit id. I don't know how useful this would be though, since the delta may contain additional file additions and removals. Also, what should we do with such tarballs whose contents are not identical to the git tree?
In the text below, I assume that:- We want to verify equality of upstreamc's tree and the one used by pristine-tar. - We allow binary deltas (i.e., the .delta file) to contain modifications to files stored in the referenced tree, such as the addition of configure scripts.
Here it is: =item C<pristine-tar>=COMMITIDIdentifies the state of the pristine-tar branch at the time of push, if present and containing data related to the current upstream version.
If this metadata item is present, the C<upstream> and C<upstream-tag> items must be present too. The tag2upload service will ensure that the tree contained in the .id file of the pristine-tar branch will correspond to the tree referenced by the commit id contained in the C<upstream> metadata item.
If the pristine-tar branch contains a signature file, this will be published together with the orig tarball, and no signature verification will be performed.
signature.asc
Description: PGP signature
