Embed Notice

@dalias@hachyderm.io @jpetazzo@hachyderm.io It defeats the purpose of the package manager which is supposed to be the one deciding what goes where. If you are shipping software standalone that is fine, but you should realize that if you want people to use it with systems that rely heavily on a package manager to do the heavy lifting you should focus on your post installation instructions. Not a minified, code golfed shell script that does god knows what. Let people figure out how to package that in their ecosystem (or, maintain your packages if you want strict control of the process) this is how it has been, this is how it should be, and anyone who deviates should be ousted. https://wiki.archlinux.org/title/PKGBUILD we have things like PKGBUILD on arch, we have all these native to a package manager's ecosystem way of doing "post install" scripts. do not just write some posix shell, or python, or perl script that requires a BUILD TIME dependency just to make your shit work.

Why is curl | sh bad? Because it's easy to see if it's curl pulling unless someone bothers to type out user agent flags and so on. Would it be bad practice to curl and then review a script? No. That requires the script to be readable though which most of these curl | sh scripts are absolutely not. I am talking about those horrific thousands of lines posix scripts that have multiple cases, falling through because no adequate testing. https://github.com/valvesoftware/steam-for-linux/issues/3671 do not be that person. it's easier to provide instructions of how to configure the software than to maintain a monolithic script that does everything for them. Not to mention that most of the time these scripts exist to bypass package manager ecosystems. cough https://rustup.rs/