4 ms·

https://github.com/tukaani-project/tukaani-project.github.io/commit/42fbb038b4f36c9d1830144bafa6c9d0d101aaa9#diff-0eb547304658805aad788d320f10bf1f292797b5e6d745

https://github.com/tukaani-project/tukaani-project.github.io/commit/42fbb038b4f36c9d1830144bafa6c9d0d101aaa9#diff-0eb547304658805aad788d320f10bf1f292797b5e6d745a3bf617584da017051R83-R87 https://github.com/tukaani-project/tukaani-project.github.io... > Note: GitHub automatically includes two archives Source code (zip) and Source code (tar.gz) in the releases. These archives cannot be disabled and should be ignored. The author was thinking ahead! Latest commit hash for this repo: 8a3b5f28d00ebc2c1619c87a8c8975718f12e271

o11c 3y ago
For a long time, there was one legitimately annoying disadvantage to the git-generated tarballs though - they lost tagging information. However, since git 2.32 (released June 2021; presumably available on GitHub by August 2021 when they blogged about it) you can use `$Format:%(describe)$` ... limited to once per repository for performance reasons.
- rany_ 3y ago
  Except this change was made in 2023, it is just scary how good this threat actor was.
- legobmw99 3y ago
  I believe they also do not include sub modules, which is a big disadvantage for some projects
  - xvilka 3y ago
    Yes. Also, GitHub recently made some upgrades that forced checksum changes on the autogenerated archives: https://github.blog/changelog/2023-01-30-git-archive-checksums-may-change/ https://github.blog/changelog/2023-01-30-git-archive-checksu...
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.

o11c 3y ago

For a long time, there was one legitimately annoying disadvantage to the git-generated tarballs though - they lost tagging information. However, since git 2.32 (released June 2021; presumably available on GitHub by August 2021 when they blogged about it) you can use `$Format:%(describe)$` ... limited to once per repository for performance reasons.

rany_ 3y ago
Except this change was made in 2023, it is just scary how good this threat actor was.
legobmw99 3y ago
I believe they also do not include sub modules, which is a big disadvantage for some projects
- xvilka 3y ago
  Yes. Also, GitHub recently made some upgrades that forced checksum changes on the autogenerated archives: https://github.blog/changelog/2023-01-30-git-archive-checksums-may-change/ https://github.blog/changelog/2023-01-30-git-archive-checksu...

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.