3 ms·

> Each platform has its own system for doing installs and upgrades. A system which is lacking either by platform convention and/or by technological capability

> Each platform has its own system for doing installs and upgrades. A system which is lacking either by platform convention and/or by technological capability to handle some now common use cases: thus the rise of second-level package managers. Homebrew, linuxbrew, rbenv/rvm, ndenv/nvm, etc. all came to the forefront because the platform's package management was not doing the job. You might pick out linuxbrew and say "ah, just use rpms/debs/etc!", but there are a lot of cases where you don't have the option to choose the distro flavor or version, which can severely limit your ability to pick up packages/versions that you need. Likewise, in most distros it's impossible to cherry-pick a single package back onto to an older release; an explicit backport must be made available. Too bad if it's not available!

stephenr 11y ago
> Homebrew Exists because OS X doesn't have a vendor-supplied "download and install this, including any dependencies" type package manager, and the existing attempts to fix it, were terrible. Frankly so is Homebrew. > linuxbrew using Beer terms is apparently cool for software packaging so lets port the idea of Homebrew back to Linux. > rbenv/rvm, ndenv/nvm rvm (and can i assume nvm, which i guess is rvm for nodejs?) is about installing multiple versions of Ruby and using them. There is nothing inherent about this concept that can't be achieved with a regular package - you're just placing compiled files in certain directories. Debian even had multiple versions of 1.x (1.8 and 1.9 from memory) that could be installed side-by-side. Even now the packages install binaries etc as e.g. `/usr/bin/ruby2.1`, so I don't buy the "traditional package managers were not doing the job". They just aren't written in hipster languages and they don't force you to compile every fucking thing you want to use on every fucking machine every fucking time you install it. > Likewise, in most distros it's impossible to cherry-pick a single package back onto to an older release; an explicit backport must be made available. Too bad if it's not available! Debian provides a pretty easy to follow guide about making your own unofficial backports, or guidance on creating official backports, and even has a basic 'auto' setup script and a "backport from a PPA" guide.
- Chlorus 11y ago
  >They just aren't written in hipster languages and they don't force you to compile every fucking thing you want to use on every fucking machine every fucking time you install it. What? Homebrew has done binaries by default for ages now.
  - derefr 11y ago
    And, in fact, so does the FreeBSD ports system it was based on. In both cases, though, the important point is that the binary is effectively a cached compilation artifact of what your computer would (hopefully) generate on its own in the default case. This means the whole workflow of package-building is still there even for binary packages; you can ask the package manager to install a package with alternate ./configure options, at which point it'll realize it has no available cached artifact for that particular configuration and build it from source instead. Honestly, after using Homebrew for a while, I find regular Linux package managers kind of naive, more like mail-order parts catalogues than a true system configuration tool. Having to consume Nginx from a PPA just to get ngx_lua support, for example: it should be as simple as an optional dependency on luajit which is enabled by an install-time "--with-lua" flag to the package manager, causing the package to be built differently.
- Karunamon 11y ago
  Can we do without needless snipes like "hipster languages" please?
- saidajigumi 11y ago
  > using Beer terms is apparently cool for software packaging so lets port the idea of Homebrew back to Linux. No, second-level package managers serve a very valuable role. They allow coeexistence of a stable base platform that packaged software (whether OS X apps or Linux packages) can target, while fully enabling the user to maintain a user-controlled and customizable set of tools. There's zero conceptual difference to what we've been doing forever with software built and installed into /usr/local, but sharing the burden of build and package maintenance. If you've ever run into the "argh, need package X (at version Y?) but $DISTRO doesn't have it!", then this is your out. > There is nothing inherent about this concept that can't be achieved with a regular package - you're just placing compiled files in certain directories. This is a statement made in a vacuum from the today-reality of Linux package managers. First everything important about the needs of 2nd-tier packaging works depends utterly on the stuff you cast aside: tooling and conventions and workflow above the mere fact of stuff-on-filesystem. In which case the devilish details of the package managers and the cultures they are embedded in are paramount. Yes, this is more about politics than technology. Distros don't want to maintain an entire suite of packages for language platforms. They pick some release they deem "stable", often with little actual sense of the needs of that language's community, and ship it. Individuals don't want to personally maintain an entire herd of packages, or have to maintain or depend on random PPAs. Also, just whipping up packages when you need a full dependency tree involving libraries that conflict with base distro versions... well good luck with all that. Example of where traditional package managers fall face-flat: The ruby/node managers allow the current version to be easily managed (and version controlled) on a per-project basis via .ruby-version/.node-version files. Good luck ever getting anything like that into any distro. > They just aren't written in hipster languages and they don't force you to compile every fucking thing you want to use on every fucking machine every fucking time you install it. [So. Much. Anger. Really?] ndenv can't build from source. It uses official upstream tarballs. Homebrew likewise has a build infrastructure and produces binary "bottles", used for almost all installs. So, whatever. >Debian provides a pretty easy to follow guide about making your own unofficial backports, or guidance on creating official backports, and even has a basic 'auto' setup script and a "backport from a PPA" guide. Which statement is willfully ignorant of the very real use cases that these 2nd tier package managers cover, such as: * Works cross-platform (ala rbenv/ndenv). OS X, .deb-based, RPM-based, etc. All good. * The aforementioned automatic version selection. (rbenv/ndenv) * Supports nearly every upstream version in a consistent manner, important for long-term project consistency/stability. (rbenv/etc) * Can't interfere with the base platform's operation. Backports done wrong can easily break stuff. These tools' strategy of never touching the QA'ed base platform is far better. (homebrew/linuxbrew) * VASTLY easier to contribute to than any distro or even (especially) a random PPA. Pull request and done. (all) * Obligatory pshaw re: making unofficial backports: "brew edit $FORMULA" and done. I've dealt with package systems from virtually every distro out there. None of them are lower ceremony and better suited to task than pretty much any of the 2nd level managers in their respective elements. On a larger point of your rant, I'll agree: Linux distros and their package managers could stand to learn a lot from the cases covered by the current crop of 2nd level managers. There are great ideas that could be "upstreamed". But all of them would need significant tooling, convention, and cultural effort to make this happen. Honestly, I can't imagine ANY Linux distro embracing these needs well in practice, and many were actively hostile when approached about same. (Cf. mailing list discussions about extended ruby and python version support before/around the time rvm was created. Don't eat within an hour beforehand.)

stephenr 11y ago

> Homebrew Exists because OS X doesn't have a vendor-supplied "download and install this, including any dependencies" type package manager, and the existing attempts to fix it, were terrible. Frankly so is Homebrew. > linuxbrew using Beer terms is apparently cool for software packaging so lets port the idea of Homebrew back to Linux. > rbenv/rvm, ndenv/nvm rvm (and can i assume nvm, which i guess is rvm for nodejs?) is about installing multiple versions of Ruby and using them. There is nothing inherent about this concept that can't be achieved with a regular package - you're just placing compiled files in certain directories. Debian even had multiple versions of 1.x (1.8 and 1.9 from memory) that could be installed side-by-side. Even now the packages install binaries etc as e.g. `/usr/bin/ruby2.1`, so I don't buy the "traditional package managers were not doing the job". They just aren't written in hipster languages and they don't force you to compile every fucking thing you want to use on every fucking machine every fucking time you install it. > Likewise, in most distros it's impossible to cherry-pick a single package back onto to an older release; an explicit backport must be made available. Too bad if it's not available! Debian provides a pretty easy to follow guide about making your own unofficial backports, or guidance on creating official backports, and even has a basic 'auto' setup script and a "backport from a PPA" guide.

Chlorus 11y ago
>They just aren't written in hipster languages and they don't force you to compile every fucking thing you want to use on every fucking machine every fucking time you install it. What? Homebrew has done binaries by default for ages now.
- derefr 11y ago
  And, in fact, so does the FreeBSD ports system it was based on. In both cases, though, the important point is that the binary is effectively a cached compilation artifact of what your computer would (hopefully) generate on its own in the default case. This means the whole workflow of package-building is still there even for binary packages; you can ask the package manager to install a package with alternate ./configure options, at which point it'll realize it has no available cached artifact for that particular configuration and build it from source instead. Honestly, after using Homebrew for a while, I find regular Linux package managers kind of naive, more like mail-order parts catalogues than a true system configuration tool. Having to consume Nginx from a PPA just to get ngx_lua support, for example: it should be as simple as an optional dependency on luajit which is enabled by an install-time "--with-lua" flag to the package manager, causing the package to be built differently.
Karunamon 11y ago
Can we do without needless snipes like "hipster languages" please?
saidajigumi 11y ago
> using Beer terms is apparently cool for software packaging so lets port the idea of Homebrew back to Linux. No, second-level package managers serve a very valuable role. They allow coeexistence of a stable base platform that packaged software (whether OS X apps or Linux packages) can target, while fully enabling the user to maintain a user-controlled and customizable set of tools. There's zero conceptual difference to what we've been doing forever with software built and installed into /usr/local, but sharing the burden of build and package maintenance. If you've ever run into the "argh, need package X (at version Y?) but $DISTRO doesn't have it!", then this is your out. > There is nothing inherent about this concept that can't be achieved with a regular package - you're just placing compiled files in certain directories. This is a statement made in a vacuum from the today-reality of Linux package managers. First everything important about the needs of 2nd-tier packaging works depends utterly on the stuff you cast aside: tooling and conventions and workflow above the mere fact of stuff-on-filesystem. In which case the devilish details of the package managers and the cultures they are embedded in are paramount. Yes, this is more about politics than technology. Distros don't want to maintain an entire suite of packages for language platforms. They pick some release they deem "stable", often with little actual sense of the needs of that language's community, and ship it. Individuals don't want to personally maintain an entire herd of packages, or have to maintain or depend on random PPAs. Also, just whipping up packages when you need a full dependency tree involving libraries that conflict with base distro versions... well good luck with all that. Example of where traditional package managers fall face-flat: The ruby/node managers allow the current version to be easily managed (and version controlled) on a per-project basis via .ruby-version/.node-version files. Good luck ever getting anything like that into any distro. > They just aren't written in hipster languages and they don't force you to compile every fucking thing you want to use on every fucking machine every fucking time you install it. [So. Much. Anger. Really?] ndenv can't build from source. It uses official upstream tarballs. Homebrew likewise has a build infrastructure and produces binary "bottles", used for almost all installs. So, whatever. >Debian provides a pretty easy to follow guide about making your own unofficial backports, or guidance on creating official backports, and even has a basic 'auto' setup script and a "backport from a PPA" guide. Which statement is willfully ignorant of the very real use cases that these 2nd tier package managers cover, such as: * Works cross-platform (ala rbenv/ndenv). OS X, .deb-based, RPM-based, etc. All good. * The aforementioned automatic version selection. (rbenv/ndenv) * Supports nearly every upstream version in a consistent manner, important for long-term project consistency/stability. (rbenv/etc) * Can't interfere with the base platform's operation. Backports done wrong can easily break stuff. These tools' strategy of never touching the QA'ed base platform is far better. (homebrew/linuxbrew) * VASTLY easier to contribute to than any distro or even (especially) a random PPA. Pull request and done. (all) * Obligatory pshaw re: making unofficial backports: "brew edit $FORMULA" and done. I've dealt with package systems from virtually every distro out there. None of them are lower ceremony and better suited to task than pretty much any of the 2nd level managers in their respective elements. On a larger point of your rant, I'll agree: Linux distros and their package managers could stand to learn a lot from the cases covered by the current crop of 2nd level managers. There are great ideas that could be "upstreamed". But all of them would need significant tooling, convention, and cultural effort to make this happen. Honestly, I can't imagine ANY Linux distro embracing these needs well in practice, and many were actively hostile when approached about same. (Cf. mailing list discussions about extended ruby and python version support before/around the time rvm was created. Don't eat within an hour beforehand.)