And while Flatpak gets a lot of criticism, I honestly think it's far better than these `script| bash` 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.
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.
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.
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.
Distrobox is basically flatpak for CLI apps. Not exactly, but it accomplishes a similar goal.
Docker is what you use if you've failed to do it the right way.
The "OMFG there's no standard way to package things on Linux!" complaint kinda sucks.
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.