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 <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.
