Andrea Pappacoda writes ("Bug#1106071: [RFC PATCH dgit v1] tag2upload: add
pristine-tar support"):
> On Fri Jul 25, 2025 at 12:00 AM CEST, Ian Jackson wrote:
> > This would be the first such, (--quilt ought to have been but is
> > grandfathered) but I think probably if someone hypothetically somehow
> > sends this option to a t2u service where this support has not yet been
> > deployed (or has been withdrawn!) what should happen? Probably it
> > should fail.
>
> Yeah, I'd make sense. If I have git-debpush adding pristine-tar
> metadata, I'm probably expecting the t2u service to use it. But maybe
> it'd make sense to make all extensions critical by default? I can't
> think of a scenario where git-debpush would add something which the t2u
> service could ignore.
We've already doucmented (and implemented in our three existing
parsers) that unknown extensions with the current syntax should be
ignored. So I don't think we should change this now.
> > So how about
> > [dgit ... !pristine-tar=... ...]
> > or
> > [dgit ... +pristine-tar=... ...]
> > or some such?
> >
> > The new metadata item will need to be documented in tag2upload(5).
>
> I like "!" more, as "+" to me has more of an "cumulative" feel.
Let's go with !.
> > What happens if another maintainer did this new upstream version, and
> > our user hasn't got that up-to-date pristine-tar branch yet? I think
> > ideally we'd use the orig from the archive, but there is a risk of
> > lossage if the uploads come too close together - see ##1109130.
>
> Maybe in the t2u service we should check if pristine-tar data exists in
> the repo and error out if the pushed tag didn't contain pristine-tar
> metadata? Because in any case, user's local builds would still be using
> a different orig than the intended one, so you're effectively testing
> your package against the wrong upstream code.
I think even if #1109130 happens, we can make the upload *fail* rather
than use the wrong orig.
But, I suggest we could deal with this by warning the user (with a
failed check) if the upstream pristine-tar branch is ahead of their
own.
> > We might want to linewrap this a bit more. That line is getting quite
> > long. I guess we could put all the upstream and pristine-tar info in
> > a separate line maybe?
>
> You mean like:
>
> [dgit distro=$distro split$quilt_mode_text]
> [dgit please-upload source=$source version=$version]
> [dgit $upstream_info$pristine_tar_info]
>
> If there's no functional difference, why not.
Yes. No, there isn't.
> > I think this option should be called "pristine_tar".
>
> Doesn't the tag2upload-obtain-origs script check that the option name
> only contains [0-9a-z-] characters? I could add an underscore there.
Huh. That makes no sense because it tries to make them into shell
varisbles! This seems like a bug in the script.
> > I don't think this is right, is it ? We want to rewind the local
> > pristine-tar branch to that commit, not the HEAD. I'm assuming
> > pristine-tar implicitly uses refs/heads/pristine-tar rather than HEAD.
>
> Yes, that's what I wanted to do. Didn't know about the existence of `git
> update-ref` (which is what I'm supposed to use here, right?). The tool
> also has a `--no-deref` option which makes me kinda nervous (having
> heard of all the security issues related to symlinks) - maybe it'd make
> sense to use that too?
We completely control the local ref namespace, because we use a
`git fetch` with refspecs, rather than `git clone`. So there won't be
unexpected symrefs.
> > We definitely don't want it to be random! Let's call this an error
> > for now.
>
> Got it. For the record, `gbp export-orig` generates the tarball
> mentioned in the most recent pristine-tar branch commit message. If the
> messages do not contain the expected tarball version, it proceeds
> assuming gzip, and if that fails, generates a new tarball with git
> archive and commits it into the pristine-tar branch. Which is probably
> less sensible than using a random one :)
Blimey.
> > If this turns out to be a problem in practice, and users don't want to
> > just git rm the unwanted info from their pristine-tar branch, then
> > I guess we'll need to add the tarball name to the tag or something.
>
> Yes, but how? If there are two tarballs of the same version in
> pristine-tar, the user might not even realise that. Which of the two
> should be added? Should the user be asked about that by git-debpush?
> It's a case which should actually never happen in practise
> (pristine-tar's objective is being able of recreating the upstream
> tarball, and usually there's just one of them).
>
> Maybe we can make git-deborig check for this too, and error out while
> creating the tag?
That would be fine. In general, things that will definitely cause the
upload to fail should be detected locally if that's reasonably
feasible.
> > If you're using git-ls-tree then you need to use the nul-separated
> > output format I think. Urgh. Feel free to switch implementation
> > language.
>
> If I can use grep and other essential: yes stuff, shell is fine. But,
> just in case, which languages are acceptable?
I think I would say Perl is fine but we probably don't want Python
without a compelling reason.
You can assume bash. The set of things installed there is already
much bigger than essential.
> Thanks for the review! Will update the code and send a v2. Bye :)
Great. I look forward to reading it.
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> 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.
