Follow-up Comment #8, sr #111238 (group autoconf):
[comment #7 comment #7:] > I apologize for saying "the distros". I meant to state what I observed > several important distros are doing. If you are working on a distro that > generally respects upstream tarballs, the "tension" that I was describing > does not exist between package maintainers and your distro. >> >>> 2) ... They run autoreconf anyway. >> We don't care if the "correct" command is autoreconf or autogen.sh > > Glad to hear that your distro is so pragmatic. I was relating my experience > with at least one major distro. Sorry for the over-generalization. No problem. :) >> I suppose that Zack has the option of pushing back against false >> information... > > I still claim that this tension exists, between specific distros and > upstream. > > Specifically Debian: https://wiki.debian.org/Autoreconf That page is a bit confusing as it gives multiple justifications. In Gentoo's experience, updating config.guess and config.sub tends to be reliable for the vast majority of cases -- we handle this separately from anything else. We *also* have an "eltpatch" program that applies backported patches to ltmain.sh for notable issues, so that we can continue using the existing build system while getting critical fixes from later versions. They also note the diff patches issue which... Okay? For packages where one is applying patches to the configure.ac it's only reasonable to also re-run autoreconf. And then they note the ideological issue of "ensure that it's possible to modify the actual source". Debian has a *lot* of opinions here. It fits quite well with the opinion of some that if a project has included vendored dependencies along with a configure --without-bundled-foobar, it's a *Debian social contract violation* if one doesn't delete the bundled code copy *before* creating a Debian source package. i.e. it's not acceptable to use the upstream release tarball even though the project is very respectful and supports both approaches, and it isn't even non-free software. They refuse to ship a .prog.tar.xz that contains the bundles code copies. Anyway, this policy predates Jia Tan, and Debian doesn't seem to require that you clean out the existing sources. That's how the malicious m4 file with a later serial number survived, after all. Probably it is because they can't enforce this, you don't know which .m4 files were automatically copied in by aclocal --install and which were handwritten... Totally impractical to enforce this. (Arch Linux is gunning for a very different policy, to add git as a build dependency for all the world's software and do a git clone from the canonical upstream repository instead of using release tarballs. That means you can't cache them offline and you can't build software if the upstream website disappears.) > Specifically openSUSE: > https://lists.opensuse.org/archives/list/packag...@lists.opensuse.org/thread/EKZEATM4VBI7XDOWFINYCNRNPI3BRD6G/ This says exactly the opposite. Someone thought the policy was to run autoreconf, didn't like it, and asked if they were really forced to do so. And got told "no, in fact please do not, we would prefer the upstream generated configure script if it is in good working order". In fact, insisting to run autoreconf even prevented backporting the package to an older SLES, which had an older autotools that was buggy and failed to build, whereas the upstream generated configure script was generated on a new system that had those fixes. ... The recent Patch release that I persuaded Andreas et al. to put together, was because over the years we collected so many patches to Patch that we had to rerun autoreconf to apply changes to configure.ac and Makefile.am; this is a *big problem* for us because it broke our ability to bootstrap Gentoo Prefix, where we don't yet have the Autotools and aren't cross compiling from a CBUILD that does. And we need Patch in order to build them. Even if it wasn't a matter of badly motivated FOSS politics, for purely practical reasons any distro that cares about bootstrapping simply cannot put up with nonsense like "we don't trust the upstream maintainer generated configure scripts". It's a pointless frippery that sets back progress. If one is concerned about the next Jia Tan, auditing source tarballs by verifying that they can be reproducibly recreated (documenting the autoconf/automake/libtool/gettext etc versions used) is the sensible and practical solution to this. If one is concerned about fixing bugs via newer autoconf/automake/libtool/gettext, it is simple to apply a two line update (in Gentoo this is "inherit the `autotools` build style") per package known to have issues and test that it works before releasing. _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/support/?111238> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/
signature.asc
Description: PGP signature
