3 ms·

> The release tarballs upstream publishes don't have the same code that GitHub has. This is common in C projects so that downstream consumers don't need to reme

by TillE 3y ago

> The release tarballs upstream publishes don't have the same code that GitHub has. This is common in C projects so that downstream consumers don't need to remember how to run autotools and autoconf. This doesn't seem really vital to the attack, but it's a silly outdated convention. Nobody is manually downloading and compiling tarballs these days, and those who do can figure out how to use autotools.

IshKebab 3y ago
Yeah terrible idea. Either you should commit the output of autoconf (and enforce keeping it up to date via CI), or much much better - stop using autoconf! It belongs in the 90s!
- knorker 3y ago
  It's another case of that "yes, it sucks. But the alternatives just plain don't work, or work in WAY fewer circumstances". If I have a strange architecture or install, autoconf is often the only one that works.
  - IshKebab 3y ago
    What strange architecture are you talking about? I don't think the cost of supporting dead architectures is worth it. CMake is a clear better choice (it also sucks but it sucks waaaay less).
    - knorker 3y ago
      I didn't want to start shitting on alternatives, but cmake is in my experience clearly the worst of all options. It seems that more often than not, cmake setups work on the developer's own machine and nothing else. And the choice of undocumented "-DSOMETHING" is about as user hostile as it gets.
frankjr 3y ago
Reminds of the note at the bottom of Fish releases. It's there because the build system cannot determine the current version for some reason. Hopefully that will go away now that they have switched to a different language / build system. The custom tarball is used by Arch Linux at the very least. https://github.com/fish-shell/fish-shell/releases/tag/3.7.1 https://github.com/fish-shell/fish-shell/releases/tag/3.7.1 https://github.com/fish-shell/fish-shell/issues/7772#issuecomment-793982192 https://github.com/fish-shell/fish-shell/issues/7772#issueco... https://gitlab.archlinux.org/archlinux/packaging/packages/fish/-/blob/661c4ae6a91a7ead1a6bdb45b186fe6d0e698fac/PKGBUILD#L22 https://gitlab.archlinux.org/archlinux/packaging/packages/fi...
k8svet 3y ago
Yes, and in fact, it's quite a huge pain even in the packaging side. Everytime I have to deal with autotools in nixpkgs, I end up having to rewrite the derivation to build from actual freaking source instead of a pre-mangled non-release tarball. In fact, this makes me want to RFC *banning* release tarball usage.
- deleted 3y ago
  [deleted]
binary132 3y ago
you mean like LLVM’s source release tars? yeah, who would do that, haha?

by TillE 3y ago

IshKebab 3y ago

Yeah terrible idea. Either you should commit the output of autoconf (and enforce keeping it up to date via CI), or much much better - stop using autoconf! It belongs in the 90s!

knorker 3y ago
It's another case of that "yes, it sucks. But the alternatives just plain don't work, or work in WAY fewer circumstances". If I have a strange architecture or install, autoconf is often the only one that works.
- IshKebab 3y ago
  What strange architecture are you talking about? I don't think the cost of supporting dead architectures is worth it. CMake is a clear better choice (it also sucks but it sucks waaaay less).
  - knorker 3y ago
    I didn't want to start shitting on alternatives, but cmake is in my experience clearly the worst of all options. It seems that more often than not, cmake setups work on the developer's own machine and nothing else. And the choice of undocumented "-DSOMETHING" is about as user hostile as it gets.

frankjr 3y ago

Reminds of the note at the bottom of Fish releases. It's there because the build system cannot determine the current version for some reason. Hopefully that will go away now that they have switched to a different language / build system. The custom tarball is used by Arch Linux at the very least. https://github.com/fish-shell/fish-shell/releases/tag/3.7.1 https://github.com/fish-shell/fish-shell/releases/tag/3.7.1 https://github.com/fish-shell/fish-shell/issues/7772#issuecomment-793982192 https://github.com/fish-shell/fish-shell/issues/7772#issueco... https://gitlab.archlinux.org/archlinux/packaging/packages/fish/-/blob/661c4ae6a91a7ead1a6bdb45b186fe6d0e698fac/PKGBUILD#L22 https://gitlab.archlinux.org/archlinux/packaging/packages/fi...

k8svet 3y ago

Yes, and in fact, it's quite a huge pain even in the packaging side. Everytime I have to deal with autotools in nixpkgs, I end up having to rewrite the derivation to build from actual freaking source instead of a pre-mangled non-release tarball. In fact, this makes me want to RFC *banning* release tarball usage.

deleted 3y ago
[deleted]

binary132 3y ago

you mean like LLVM’s source release tars? yeah, who would do that, haha?