Andrea Pappacoda writes ("Re: Bug#1106071: [RFC PATCH dgit v2] tag2upload: add
pristine-tar support"):
> 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>=COMMITID
I think we decided it should start with !.
I will add something to the spec about critical extensions starting
with !.
> Identifies the state of the pristine-tar branch at the time of push, if
> present and containing data related to the current upstream version.
This is ind kof in the wrong mood. It reads like a description of
when git-debpush should include it. It ought instead to be a
specification of what meaning of the item is.
Something like
Names a commit containing pristine-tar metadata.
The commit must contain SOMETHING LIKE exactly one .id file with
SOME PROPERTIES OR OTHER. The .id file MUST SATISFY SOME
CONDITIONS THAT I DON'T UNDERSTAND.
The tag must also contain an C<upstream> item, and the tree named in
the .id file must be identical to that of the C<upstream> commit.
The pristine-tar commit may contain SOMEHOW IDENTIFIABLE signature
file. The signature file MUST SATISFY REASONAB.E CONDITIONS SUCH AS
ITS FILENAME BEING SANE. The signature file will then be published
together with the orig tarball. The signature file is treated as
pure data by the service (so will not be verified or even format
checked).
If an orig tarball needs to be (re)generated, the service will use
pristine-tar, using precixely the metadata in the .id file. The
service will check that the generated tarball MATCHES THE HASH IN
THE .ID FILE and that its contained tree is identical to SOMETHING.
The named prstine-tar commit must be reachable from the
C<pristine-tar> branch in the repository.
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.
