8 ms·

Curl to shell is usually indicative of a package manager that could be doing a better job.

meddlepal 7y ago
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.
- commandlinefan 7y ago
  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.
  - mbreese 7y ago
    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)
    - debiandev 7y ago
      ...not to mention that (some) distributions do extensive security and legal compliance reviews...
- mbreese 7y ago
  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.
  - dmitriid 7y ago
    > 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.
    - notabee 7y ago
      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.
      - dmitriid 7y ago
        > 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.
- debiandev 7y ago
  That's what distributions are for. Just write software that is not unnecessarily difficult to package.

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.

commandlinefan 7y ago
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.
- mbreese 7y ago
  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)
  - debiandev 7y ago
    ...not to mention that (some) distributions do extensive security and legal compliance reviews...
mbreese 7y ago
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.
- dmitriid 7y ago
  > 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.
  - notabee 7y ago
    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.
    - dmitriid 7y ago
      > 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.
debiandev 7y ago
That's what distributions are for. Just write software that is not unnecessarily difficult to package.