Package: dgit-infrastructure
Version: 13.0
Severity: wishlist
tl;dr:
tag2upload ought to support, but not recommend or encourage,
pristine-tar. But I'm probably not the person to implemnt it.
Desirability of pristine-tar
----------------------------
Currently, tsg2upload doesn't support pristine-tar. For
new-upstream-version uploads, it will use `git-deborig` which is a
thin wrapper around `git-archive`. After #1105862 it will try to
detect when the user was trying to use pristine-tar, and fail.
pristine-tar's purpose is to mitigate some of the inconvenience of the
doctrine that Debian should base its work on, and redistribute,
upstream tarballs. Personally, I think that doctrine is obsolete,
even harmful, for a large majority of upstreams. Also, pristine-tar
is something of a hack and doesn't always work.
So my personal view is that pristine-tar is largely pointless
complexity to support an inferior workflow - indeed, a workflow that
exposes us to greater upstream supply chain risk since upstream
tarballs are less trustworthy than upstream git.
However, a key goal of tag2upload (and indeed my whole git transition
project) is to try to meet people where they are - and that includes
supporting partial transitions from tarballs+patches to git. I think pristine-tar falls into this category.
Therefore I think tag2upload *should* support pristine-tar.
But we should definitely recommend against it, and not put any
barriers in the way of people who don't use pristine-tar.
Implementation
--------------
I have almost never used pristine-tar and I don't intend to adopt it
now. I don't really know how it works - what git refs it uses, what
the contents are, what invariants it preserves, and so on. I think
the design and implementation would have to be done by someone who
does understand these things (and can explain them to me).
I think the ingredients (and skills needed) would be:
* Some new metadata item(s) in the please-upload tag, including
details of precisely which pristine-tar git objects are to be used,
and maybe what refs they are to be fetched from if that's not
obvious. (Security and correctness design; pristine-tar.)
* Recheck the code in git-debpush that does pristine-tar detection,
which we are currently adding as part of #1105862 (which is just to
detect use of pristine-tar and *reject*, to avoid mistakes).
If we're going to use it to control the output, rather than merely
as a safety catch against mistakes, It needs to be reliable.
(Security and correctness design; pristine-tar; bash.)
* Code in git-debpush to check that the pristine-tar information is
consistent with the rest of the git information. In particular, we
must check that the tarball implied by pristine-tar is treesame to
the upstream tag. IDK if this is true by pristine-tar's design.
(Security and correctness design; pristine-tar; bash.)
* Given the design, code in dgit-repos-server to parse the new tag
metadata, fetch the pristine-tar objects (easy) and run
pristine-tar (probably also easy). (Perl; pristine-tar; help from
tag2upload authors.)
* Change in tag2upload-service-manager to tolerate but ignore the new
critical metadata item in the tag. (Rust; easy.)
* Test cases in dgit.git. (Bash; Perl; pristine-tar. Help wrestling
the test suite from the src:dgit maintainers.)
References
----------
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1105862
git-debpush check to detect and fail if user wanted pristine-tar
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=891033
request for dgit to use pristine-tar automatically
Anyone who is interested in working on this should please get in
touch.
Ian.
--
Ian Jackson <
ijackson@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.
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)