Re: Validating tarballs against git repositories
Luca Boccassi <bluca@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.
> When using Meson/CMake/home-grown makefiles there's no meaningful
> difference on average, although I'm sure there are corner cases and
> exceptions here and there.
Yes, perhaps it's time to switch to a different build system, although one
of the reasons I've personally been putting this off is that I do a lot of
feature probing for library APIs that have changed over time, and I'm not
sure how one does that in the non-Autoconf build systems. Meson's Porting
from Autotools [1] page, for example, doesn't seem to address this use
case at all.
[1] https://mesonbuild.com/Porting-from-autotools.html
Maybe the answer is "you should give up on portability to older systems as
the cost of having a cleaner build system," and that's not an entirely
unreasonable thing to say, but that's going to be a hard sell for a lot of
upstreams that care immensely about this.
--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: