Small clarification to old discussion: Hello, Ludovic Courtès writes: > Hi! > > Maxime Devos skribis: > >> Ludovic Courtès schreef op vr 01-04-2022 om 10:58 [+0200]: >>> As a first milestone, maybe we could start running ‘autoreconf’ more >>> often, for packages higher in the graph. We could change the >>> ‘bootstrap’ build phase to do that unless it’s explicitly turned off. >>> It may turn out to be a Sisyphean task though… >>> >>> Thoughts? >> >> Changing all pre-existing packages, maybe. But doing this for new >> packages (reducing review effort) and perhaps when a package is updated >> (for purity) should be feasible I think? Then gradually things would >> improve and eventually(TM) doing the switch in the bootstrap phase may >> become feasible ... > > Yes, we could do that as a first step (in fact it’s already happening as > some projects no longer distribute tarballs). > > What do maintainers think of that policy? No strong opinion, but I agree that having a complete development environment capable of building from the bare sources (e.g. a git tree) is useful in general. On the other hand, using tarballs is often more efficient and practical (it's made to be built by downstream users, rather than by developers, so it includes everything needed). Release tarballs are also often signed by the projects, which is neat. So perhaps we can leave some flexibility there and not make it a hard rule, but a case of best judgment? We can both use tarballs _and_ unbundle/regenerate, no need to switch from tarball to git (though that's one way to do things)! E.g., adjust the bootstrap phase to always "autoreconf -vif" and/or add snippets or post-unpack phases to remove generated or bundled Autotools files. Greetings, Maxime.