The problem with deb, rpm, etc is that you need to add instructions to all supported systems one by one. Check out this site for reference: https://www.sublimemerge.com/docs/linux_repositories and compare with curl URL|sh that can detect target system and delegate to appropriate system. Much simpler.

The root cause of this is no universal packaging format for Linux in my opinion.

> The root cause of this is no universal packaging format for Linux in my opinion.

Which some have attempted to solve, so now we also have Flatpack, AppImage, and Snap -- each with their own little issues.

I understand the difficulty. But if you're going to write a shell script that detects the target system and takes different actions, you might as well move that logic to the packaging system. It's much more robust, especially when it comes to dependency management and updating.

I wish there were a simple, modern, easily configurable tool that can take a declarative description of a project and spit out a ready-to-serve repository (just point nginx at it!) for most commonly used package formats. For Linux daemons this should be easier than ever before, now that systemd has gobbled up all the major distros.

> you might as well move that logic to the packaging system

Depends on who do you mean by "you". Software vendor can definitely write a script but they have no power over distributions to "move that logic to the packaging system".

This would have to be a collaborative work by different distros but from my casual look it's just not happening as everyone is happy with their own package manager that's "obviously the best".

I do agree on systemd. I didn't like it before I moved to Linux now I see a lot of value that it brings.

This may also be relevant: http://0pointer.net/blog/revisiting-how-we-put-together-linu...

> This would have to be a collaborative work by different distros

I think there was a misunderstanding between us. I didn't mean anything so complicated.

By "moving that logic to the packaging system", all I meant is that instead of using a script to detect whether your app is being installed on Ubuntu or Fedora or whatever, you should just build and publish separate packages for each distro you wish to support. The logic for selecting the right package for itself is already built into every packaging system, ready for anyone to use.

Hopefully the process of building a dozen packages with each release can be easily automated once it is set up.

If you want to support multiple platforms this is the way to go. I don't see a problem with it.

We have the freedom to use different package managers. It comes, likes everything else, with it's own drawbacks.

What’s the difference between a curl you blindly pipe into sh and a blind brew install/npm install command?

Based on experience, brew will place files in a place that I expect.

I can’t predict where a shell script will scribble or what other changes it will make to my system.

A brew recipe is a ruby program that can do anything on your computer. It will and does invoke any number of external processes, including: downloading and executing other recipes, running any number of compilers, arbitrary binary executables, and shell scripts, creating and linking executables, overriding system-provided binaries and libs, etc. etc. etc.

All these recipes and scripts are supposedly downloaded from GitHub. With supposedly anonymous user analytics: https://github.com/Homebrew/brew/blob/master/docs/Analytics....

isn't brew itself a curl'd script?

Installing brew is basically curl|ruby. But that's somewhat forgivable because you need to install a package manager before you can use a package manager.

The lack of information. Most install docs tell about installation requirements. One-liners don't.