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. And said upstreams might care about this because they support backward compatibility with ancient Unix stuff and such like (I mean, I _am_ upstream in one project that does exactly this for exactly this reason, zeromq, so I understand that requirement perfectly well). 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.
