Btw, this is not the only project providing a source tarball different from the git repo, for example libusb also does this (and probably others):
- https://github.com/libusb/libusb/issues/1468#issuecomment-19...
- https://github.com/libusb/libusb/issues/1468#issuecomment-19...
Autotools are not guaranteed to be installed on any system. For example they aren't on the OSX runners of GitHub Action.
It's also an issue with UX. autoreconf fails are pretty common. If you don't make it easy for your users to actually use your project, you lose out on some.
Like a compiler or some -devel packages?
The more steps you add to get to the final product the more likely it is to run into problems.
Built artifacts shouldn't require build-time dependencies to be installed, yes, but we're talking about source distributions. Including `./configure` is just a way of reducing the configuration-/build-time dependencies for the user.
> Autotools are not guaranteed to be installed on any system. [...]
Which is why this is common practice.
> It's common but it's plain wrong.
Strong word. I'm not sure it's "plain wrong". We could just require that users have autoconf installed in order to build from sources, or we could commit `./configure` whenever we make a release, or we could continue this approach. (For some royal we.)
But stopping this practice won't prevent backdoors. I think a lot of people in this thread are focusing on this as if it was the source of all evils, but it's really not.
Very strange argument. It’s like saying our source release only contains a prebuilt binary, otherwise the user has to run “make”.
If that’s such a big hassle for your downstream consumers, maybe one should use something better than autoconf in the first place.
It's also not the distribution model for an Autotools project. Project distributions would include a handwritten configure file that users would run: The usual `./configure && make && make install`. Since those configure scripts became more and more complex for supporting diverse combinations of compiler and OS, the idea of autotools was for maintainers to generate it. It was not meant to be executed by the user: https://en.wikipedia.org/wiki/GNU_Autotools#Usage
I have autotools installed and despite that autoreconf fails for me on the xz git repository.
The idea of having configure as a convoluted shell script is that it runs everywhere without any additional. If it isn't committed to the repository you're burdening your consumers with having compilation dependencies installed that are not needed for running your software.
You don’t need gcc to run the software. It’s not burdening anyone that gcc was needed to build the software.
It’s very standard practice to have development dependencies. Why should autoconf be treated exceptionally?
If they fail despite being available it’s either a sign of using a fragile tool or a badly maintained project. Both can be fixed without shipping a half-pre-compiled-half-source repo.
The more steps you add to get final product the more errors are possible. It's much easier for you as the project developer to generate the script so you should do it.
If it's easier for you to generate the binary, you should do it as well (reproducible binaries of course). That's why Windows binaries are often shipped. With Linux binaries this is much harder (even though there are solutions now). With OSX it depends if you have the newest CPU architecture or not.
I think that's the crux of what you're saying. But consider that if Fedora, Debian, etc. accepted released, built artifacts from upstreams then it would be even easier to introduce backdoors!
Fedora, Debian, Nix -all the distros- need to build from sources, preferably from sources taken from upstreams' version control repositories. Not that that would prevent backdoors -it wouldn't!- but that it would at least make it easier to investigate later as the sources would all be visible to the distros (assuming non-backdoored build tools).