Luca Boccassi <bl...@debian.org> writes: > On Sat, 30 Mar 2024 at 15:44, Russ Allbery <r...@debian.org> wrote: >> Luca Boccassi <bl...@debian.org> writes:
>>> In the end, massaged tarballs were needed to avoid rerunning >>> autoconfery on twelve thousands different proprietary and >>> non-proprietary Unix variants, back in the day. In 2024, we do >>> dh_autoreconf by default so it's all moot anyway. >> This is true from Debian's perspective. This is much less obviously >> true from upstream's perspective, and there are some advantages to >> aligning with upstream about what constitutes the release artifact. > My point is that, while there will be for sure exceptions here and > there, by and large the need for massaged tarballs comes from projects > using autoconf and wanting to ship source archives that do not require > to run the autoconf machinery. Just as a data point, literally every C project for which I am upstream ships additional files in the release tarballs that are not in Git for reasons unrelated to Autoconf and friends. Most of this is pregenerated documentation (primarily man pages generated from POD), but it also includes generated test data and other things. The reason is similar: regenerating those files requires tools that may not be present on an older system (like a mess of random Perl modules) or, in the case of the man pages, may be old and thus produce significantly inferior output. > However, we as in Debian do not have this problem. We can and do re-run > the autoconf machinery on every build. And at least on the main forges, > the autogenerated (and thus out of reach from this kind of attacks) > tarball is always present too - the massaged tarball is an _addition_, > not a _substitution_. Hence: we should really really think about forcing > all packages, by policy, to use the autogenerated tarball by default > instead of the autoconf one, when both are present, unless extenuating > circumstances (that have to be documented) are present. I think this is probably right as long as by "autogenerated" you mean basing the Debian package on a signed upstream Git tag and *locally* generating a tarball to satisfy Debian's .orig.tar.gz requirement, not using GitHub's autogenerated tarball that has all sorts of other potential issues. Just to note, though, this means that we lose the upstream signature in the archive. The only place the upstream signature would then live is in Salsa. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
