4 ms·

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://gi

by rom1v 3y ago

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-1974787595 https://github.com/libusb/libusb/issues/1468#issuecomment-19... - https://github.com/orgs/community/discussions/6003 https://github.com/orgs/community/discussions/6003

cryptonector 3y ago
It's very common in autoconf codebases because the idea is that you untar and then run `./configure ...` rather than `autoreconf -fi && ./configure ...`. But to do that either you have to commit `./configure` or you have to make a separate tarball (typically with `make dist`). I know because two projects I co-maintain do this.
- Too 3y ago
  Whats the problem of running “autoreconf -fi” though? 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.
  - bhaak 3y ago
    For running autoreconf you need to have autotools installed and even then it can fail. 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.
    - Too 3y ago
      Yes...For running gcc you need to have gcc installed. 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.
      - bhaak 3y ago
        The configure script is not a compilation artifact. 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.
        cryptonector 3y ago
        > If it's easier for you to generate the binary, you should do it as well (reproducible binaries of course). 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).
  - meinersbur 3y ago
    Autotools are not backwards-compatible. Often only a specific version of autotools works. Only the generated configure is supposed to be portable. 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 https://en.wikipedia.org/wiki/GNU_Autotools#Usage
- bhaak 3y ago
  It's common but it's plain wrong. A "release" should allow to build the project without installing dependencies that are only there for compilation. 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.
  - GrayShade 3y ago
    > A "release" should allow to build the project without installing dependencies that are only there for compilation. Like a compiler or some -devel packages?
    - bhaak 3y ago
      If the compiler is some customized or hard to build version then yes, they should be included. The more steps you add to get to the final product the more likely it is to run into problems.
  - cryptonector 3y ago
    > [...] A "release" should allow to build the project without installing dependencies that are only there for compilation. 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.

by rom1v 3y ago

cryptonector 3y ago

It's very common in autoconf codebases because the idea is that you untar and then run `./configure ...` rather than `autoreconf -fi && ./configure ...`. But to do that either you have to commit `./configure` or you have to make a separate tarball (typically with `make dist`). I know because two projects I co-maintain do this.

Too 3y ago
Whats the problem of running “autoreconf -fi” though? 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.
- bhaak 3y ago
  For running autoreconf you need to have autotools installed and even then it can fail. 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.
  - Too 3y ago
    Yes...For running gcc you need to have gcc installed. 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.
    - bhaak 3y ago
      The configure script is not a compilation artifact. 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.
      - cryptonector 3y ago
        > If it's easier for you to generate the binary, you should do it as well (reproducible binaries of course). 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).
- meinersbur 3y ago
  Autotools are not backwards-compatible. Often only a specific version of autotools works. Only the generated configure is supposed to be portable. 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 https://en.wikipedia.org/wiki/GNU_Autotools#Usage
bhaak 3y ago
It's common but it's plain wrong. A "release" should allow to build the project without installing dependencies that are only there for compilation. 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.
- GrayShade 3y ago
  > A "release" should allow to build the project without installing dependencies that are only there for compilation. Like a compiler or some -devel packages?
  - bhaak 3y ago
    If the compiler is some customized or hard to build version then yes, they should be included. The more steps you add to get to the final product the more likely it is to run into problems.
- cryptonector 3y ago
  > [...] A "release" should allow to build the project without installing dependencies that are only there for compilation. 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.