Hi Sean!
On Sat Aug 2, 2025 at 12:20 PM CEST, Sean Whitton wrote:
Have you had a chance to look at the following?
Sorry, I thought I had replied already. Thanks for the reminder :)
On Mon 28 Jul 2025 at 08:19pm +01, Ian Jackson wrote:
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 branch must contain exactly one .id file per upstream release. Its
name should correspond to the name of the orig tarball, with the ".id"
suffix. The file must be a regular file.
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.
Yes.
The pristine-tar commit may contain SOMEHOW IDENTIFIABLE signature
file. The signature file MUST SATISFY REASONAB.E CONDITIONS SUCH
AS ITS FILENAME BEING SANE.
In practise, pristine-tar always stores the signature file as
"orig_name.asc". So I think we could just specify this requirement here.
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).
Yes.
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.
I'm not sure I get this part, but if you meant what I understood, then
it's wrong. The .id file does not contain the hash of the tarball, it
contains a single line which corresponds to the tree id, as mentioned
above. I'm honestly not sure where the hash verification happens, but *i
believe* it's part of the reconstruction when pristine-gz and co re run,
thanks to information stored in the .delta (VCDIFF) file.
The named prstine-tar commit must be reachable from the
C<pristine-tar> branch in the repository.
Yes.
One question remains unanswered. Should we allow .delta files modifying
the tarball contents (i.e., do we want to allow generating tarballs
which have different contents then the git tree)?
