3 ms·

> Sounds horrifying Let's break this down. > Macports is generally much slower to install packages MacPorts and Homebrew are both source-based package manage

by pxc 5y ago

> Sounds horrifying Let's break this down. > Macports is generally much slower to install packages MacPorts and Homebrew are both source-based package managers. Distributing source code to be compiled on install is the basic design of both. And both also have binary caches. I think compared to the size of each package collection, Homebrew's binary cache is more complete, so it might save you some time sometimes. (As package managers go, though, Homebrew is extremely slow.) > Macports installs packages under “/opt/local” This is much better behavior than taking over /usr/local, which is generally for packages you install manually. It's much more portable and much less prone to compatibility problems. > Macports uses root, which can lead to users goofing up their system or workplace policy issues Homebrew uses root and it just hides from you that it uses root by giving ownership of /usr/local to your particular user, which constitutes a system policy issue. It's a security problem and it's also just a disgusting thing to do on a nominally multi-user operating system. The only one of these issues where Homebrew wins is with the binary cache size (which has apparently come at the cost of reducing customizability for many Homebrew packages, if the comments of longtime Homebrew users on GitHub and HN are to be believed).

rapsey 5y ago
There is nothing keeping you from installing homebrew in your home folder. It is completely painless. No root required.
- ck45 5y ago
  No, it’s not completely painless. You need to recompile a lot of packages and are spammed with warnings.
  - rapsey 5y ago
    I have had zero warning spam and no issues and I use it a lot.
    - pxc 5y ago
      If you run `brew doctor` on a brew installation with a custom prefix, you get several spurious warnings depending on what all you have installed. It's not spam, but it is annoying if you're trying to use `brew doctor` in an automated process.
- pimlottc 5y ago
  I wouldn't call it completely painless when I tried it a few years ago. Compile times can be very long for some packages (try installing pandoc and all its required dependencies) and there were definitely a few package that just didn't work, though I don't remember which ones now.
saghm 5y ago
> This is much better behavior than taking over /usr/local, which is generally for packages you install manually. It's much more portable and much less prone to compatibility problems. Isn't using `/usr/local` pretty standard for BSDs? I remember that on FreeBSD the package manager installs things there, and I _think_ NetBSD and OpenBSD might also, but it's been so long that I've played around with them that I can't remember for sure.
- pxc 5y ago
  NetBSD's package manager is pkgsrc, which (at least on foreign systems) uses /usr/pkg for the source tree and /opt/pkg for installs. While ports packages are always considered 'optional', they are sometimes first-party (as opposed to 'foreign') in the sense that they're made by the same community of developers as the base system, and they are universally expected to be the main package manager on that particular OS. I think usage of /usr/local as an install prefix is more typical for ports systems that are 'first-party' in this sense. When Homebrew was created, MacPorts already used /usr/local, and Homebrew's choice to do the same made them incompatible with one another. /usr/local is also directly used by language-specific package managers for global package installs by default, which is another potential source of conflict. Because /usr/local is on a lot of default search paths, it's more likely that libraries installed there will be picked up by default by random programs on the system (both at build time and at runtime). This is somewhat convenient, especially if you want your package manager to modify the behavior of the underlying base system. But it's also less portable, less predictable, and more presumptuous in that it is more likely to cause conflicts with other tools (and thus assumes/asserts that you won't use them). For these reasons, most ports systems that target foreign operating systems (e.g., Pkgsrc, MacPorts, Ravenports, Gentoo Prefix, and, oddly enough, Linuxbrew) don't target or recommend /usr/local as the default install prefix.

by pxc 5y ago

rapsey 5y ago

There is nothing keeping you from installing homebrew in your home folder. It is completely painless. No root required.

ck45 5y ago
No, it’s not completely painless. You need to recompile a lot of packages and are spammed with warnings.
- rapsey 5y ago
  I have had zero warning spam and no issues and I use it a lot.
  - pxc 5y ago
    If you run `brew doctor` on a brew installation with a custom prefix, you get several spurious warnings depending on what all you have installed. It's not spam, but it is annoying if you're trying to use `brew doctor` in an automated process.
pimlottc 5y ago
I wouldn't call it completely painless when I tried it a few years ago. Compile times can be very long for some packages (try installing pandoc and all its required dependencies) and there were definitely a few package that just didn't work, though I don't remember which ones now.

saghm 5y ago

> This is much better behavior than taking over /usr/local, which is generally for packages you install manually. It's much more portable and much less prone to compatibility problems. Isn't using `/usr/local` pretty standard for BSDs? I remember that on FreeBSD the package manager installs things there, and I _think_ NetBSD and OpenBSD might also, but it's been so long that I've played around with them that I can't remember for sure.

pxc 5y ago
NetBSD's package manager is pkgsrc, which (at least on foreign systems) uses /usr/pkg for the source tree and /opt/pkg for installs. While ports packages are always considered 'optional', they are sometimes first-party (as opposed to 'foreign') in the sense that they're made by the same community of developers as the base system, and they are universally expected to be the main package manager on that particular OS. I think usage of /usr/local as an install prefix is more typical for ports systems that are 'first-party' in this sense. When Homebrew was created, MacPorts already used /usr/local, and Homebrew's choice to do the same made them incompatible with one another. /usr/local is also directly used by language-specific package managers for global package installs by default, which is another potential source of conflict. Because /usr/local is on a lot of default search paths, it's more likely that libraries installed there will be picked up by default by random programs on the system (both at build time and at runtime). This is somewhat convenient, especially if you want your package manager to modify the behavior of the underlying base system. But it's also less portable, less predictable, and more presumptuous in that it is more likely to cause conflicts with other tools (and thus assumes/asserts that you won't use them). For these reasons, most ports systems that target foreign operating systems (e.g., Pkgsrc, MacPorts, Ravenports, Gentoo Prefix, and, oddly enough, Linuxbrew) don't target or recommend /usr/local as the default install prefix.