If only there was one standard package manager... dealing with brew/apt/[yum|dnf] and handling multiple yearly vendor releases (Ubuntu and Fedora) gets to be annoying.
And some random shell script installer is going to better than a dedicated package manager at dealing with the differences between N many distributions and M many architectures?
Sure, some install scripts will be quite simple, but in that case, why do you need to have the install script in the first place? You'd only need it if the installation procedure was too complicated for an `INSTALL` or `README` document.
> And some random shell script installer is going to better than a dedicated package manager at dealing with the differences between N many distributions and M many architectures?
Surprisingly, yes. Especially for *nix systems where a lot of things (but not package managers) are more-or-less unified. The author may not have the time or desire to learn the half-a-dozen or so package managers and set up a build system to create packages for all of those, and then do the work of getting them into the standard repositories.
Well I guess if that's too much trouble, then why write documentation either? That's extra work and people could just read the code. And so on. Ultimately, the effort put in to proper distribution reflects on the maturity of the project. On the other hand, there's nothing stopping users from submitting things like rpm specs upstream either if they're requested.
> Well I guess if that's too much trouble, then why write documentation either?
Bad guess.
> Ultimately, the effort put in to proper distribution reflects on the maturity of the project
For some, maybe. Even though there maturity of the project is reflected by how timely three bugs are fixed, quality of docs, size of community, development of new features.
Not only that, but I always end up with impossible-to-diagnose phantom errors if I start mixing and matching some installations from package manager and some installations from elsewhere (like curl | sh or ./configure, make, make install). I avoid using package managers as much as possible because they do too much hidden, undoable, inscrutable magic behind the scenes that breaks everything when it’s most inconvenient.
And here, I go the other way -- I keep to only using package managers as much as possible because at least they have some coherent plan for where installation data should go. Random install scripts can put data anywhere and can easily mess with global or system installed data. If I can't set the installation prefix myself, I don't use the code.
(I'm sure this issue has something to do with the popularity of containers)
