[lpln3452]

Admittedly, a distro agnostic equivalent to the PKGBUILD or Nix Flakes would have been great. But it's hard to excuse them when so many better alternatives are available. Even apps that could easily be built into a single binary use these odd installation methods.

And while Flatpak gets a lot of criticism, I honestly think it's far better than these `script| bash` methods.

[IshKebab]

> Even apps that could easily be built into a single binary use these odd installation methods.

Yeah because the curl bash script can deal with automatically selecting the right binary (even on Mac) and adding it to your PATH.

> And while Flatpak gets a lot of criticism, I honestly think it's far better than these `script| bash` methods.

I agree but does Flatpak actually work for CLI tools (which is where I see most use of curl-bash). E.g. could I install Rust using Flatpak? My understanding was it's more suited for sandboxed GUI apps.

[ac29]

> I agree but does Flatpak actually work for CLI tools (which is where I see most use of curl-bash). E.g. could I install Rust using Flatpak? My understanding was it's more suited for sandboxed GUI apps.

Distrobox is basically flatpak for CLI apps. Not exactly, but it accomplishes a similar goal.

[IshKebab]

Doesn't it use Docker? Fine for trying stuff out on different distros but there's no way I want Docker as a normal installation process.

Docker is what you use if you've failed to do it the right way.

[lpln3452]

No. It is absolutely ridiculous to suggest that one must read some unknown script just for the simple task of adding a binary to the directory on PATH. Unless, of course, you're the type of person who just runs any script without verification.

Furthermore, for files installed 'automatically' like that, it's nearly impossible to remember what was done and where. This means that to remove it, you have to find and read 'that specific version' of the script you ran, and then delete the files. It's not like the script is always in a place with a persistent history, like a git repository. Good luck with that.

[IshKebab]

Yeah uninstallation is a flaw, but what alternative are you suggesting?

And yes I am the type of person that uses heuristics to trust what software to run. You aren't magically safer if you audit the install script and not the actual binary.

[lpln3452]

The smaller the attack surface, the better. There is no need to expand it unnecessarily. By your logic, we shouldn't even use the binaries provided by the official package manager, because they also cannot be trusted.

We are talking about the dangers of the installation method. Not the program itself.

[IshKebab]

> We are talking about the dangers of the installation method. Not the program itself.

It only makes sense to separate them if you install the program and then never run it which is obviously ridiculous.

> There is no need to expand it unnecessarily.

I agree, but it is necessary because there aren't any good alternatives.

Also it is very minimal additional risk. If it wasn't we'd see it used as an attack method and as far as I know that has yet to happen once.

[simoncion]

Yeah, honestly, package your thing up as either a .DEB or an .RPM. 'alien' [0] will handle converting from one to the other, and that will take care of like 90->98% of the Linux users out there.

The "OMFG there's no standard way to package things on Linux!" complaint kinda sucks.

[0] <https://wiki.debian.org/Alien>

[lpln3452]

Actually, I don't use Debian or Ubuntu either, and I don't think it's a good idea to only support those methods.

[simoncion]

> ...I don't use Debian or Ubuntu...

Neither do I.

I've been using Gentoo for twenty-three years (since 2002). I stopped looking for equally-well-managed alternatives somewhere between 2012 and 2015. I have enough local compute that the build times for everything other than Chromium aren't a problem. If I didn't, I could use the official prebuilt binary packages that have been around for a few years.

> ...I don't think it's a good idea to only support [.deb or .rpm packages].

If you can do more, you should, yes. However, -as a hobbyist open-source programmer- I recognize that other hobbyists only have so much time and giveashit available.

The absolute best thing they can do is provide a source tarball that builds and installs correctly with './configure && make && make install' [0] or the language-specific equivalent. Any competent distro package management system will make it somewhere between trivial and pretty easy for others to package projects like this up. [1]

If they have more time and giveashit available, make prebuilt .deb packages so that your software is trivially installable for the most users out there. If you find yourself with more spare resources, then write packages for other OS package managers to get the remaining small fraction of Linux users.

The absolute worst thing to do would be to assume you MUST package your software for every distro out there (lest someone whine at you on the Internet), decide that that's way too much work, and not publish anything. As someone who has many, many unstarted projects because they seem like way too much work, I can tell you that that's a totally real failure mode.

[0] Perhaps with an optional side-trip to 'make test'.

[1] Unless they're using something godawful to package like NodeJS.

[cestith]

fpm (Effing package manager) goes far beyond what alien does, too, in case you need even more flexibility.

https://fpm.readthedocs.io/en/latest/getting-started.html

[simoncion]

Neat. That I didn't know about this probably says something about how long it has been since I needed something like alien.