Simon Josefsson writes ("Re: Include git commit id and git tree id in *.changes
files when uploading? [and 1 more messages]"):
> Ian Jackson <[email protected]> writes:
> > xzcat emacs-llama_1.0.3.orig.tar.xz | git-get-tar-commit-id
> > 2a89ba755b0459914a44b1ffa793e57f759a5b85
>
> That would only match upstream commit if 'emacs-llama' pin the
> tag2upload upstream git commit to the actual upstream git commit, right?
I'm not sure what you mean by "pin" here. But, yes, we would
recommending using actual upstream git.
> Which it does for this package: [demonstration]
...
> However, I think for many packages, that is not what is happening,
> because the tag2upload upstream git commit will be the 'upstream/1.2.3'
> tag that is created by 'gbp import-orig'. Which is Debian-specific
Yes, this is true.
We would generally recommend against using gbp import-orig. If the
upstream orig tarball came out of git-archive then importing it into
git again is at best pointless, and if the upstream tarball waa
generated in some other way by upstream, it can be hazardous.
To put it more tendentiously: gbp import-orig's function is to import
the xz attack trigger, from the hard-to-audit upstream tarball, into
Debian's git, so that we can ship the vulnerable library, despite the
attack being only in dormant files in a test subdir in upstream git.
This relieves Jia Tan of the need to put the attack trigger into git
where it is more visible so more likely to be detected.
But, does gbp import-orig not base its history on the upstream
history? So if the upstream tarball was made with git-archive, the
commit referenced by the gbp import-orig tag will be treesame to the
actual upstream release tag. So in this situation the traceability is
worse, but not catastrophically so.
Anyway: a user who is determined to use gbp import-orig has presumably
subscribed to the "pristine upstream tarballs" doctrine and would want
tag2upload to reproduce that tarball. That requires pristine-tar.
This kind of situation is one reason why we *do* want to support
pristine-tar. It's popular, even though it's usually a bad idea.
So we we want to support it, so that tag2upload produces the best
possible output, even when people do the bad normal-for-Debian thing.
> This leads to me to believe that it would be better to use 'git-debpush
> --upstream-tag=v1.2.3' instead of 'git-debpush
> --upstream-tag=upstream/1.2.3', right?
Yes.
> I've been mixing those two styles in my uploads, to experiment with the
> effect, and pending any recommendations on this. I haven't seen any
> noticiable difference between these two styles, and mix between them
> somewhat randomly to gain experience.
>
> Is there any advantage to using --upstream-tag=upstream/1.2.3?
If your upstream's origs come from git-archive, none.
If they don't then changing to use upstream git as your source of
truth rather than upstream tarballs might be some work, but is
definitely a good idea.
The only time when you'd want to use gbp import-orig is if upstream
don't use git, or their git is wholly unuseable for some reason.
> I thought that the 'git-deborig' design somehow prefered upstream/1.2.3
> tag but that could be my mistake (my intuition for all of this is still
> in training mode and often wrong, it seems).
It's possible that the default there should be improved.
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.
