3 ms·
At least you're missing out on bottles (pre-built formulae) when your prefix is not /usr/local. EDIT: The rationale for using /usr/local has been explained in
by dancek 10y ago
At least you're missing out on bottles (pre-built formulae) when your prefix is not /usr/local.
EDIT: The rationale for using /usr/local has been explained in the FAQ: https://github.com/Homebrew/brew/blob/master/docs/FAQ.md#why-does-homebrew-prefer-i-install-to-usrlocal https://github.com/Homebrew/brew/blob/master/docs/FAQ.md#why...
- lloeki 10y agoThe points are opinionated (which is nice!) but a tad obsolete these days. 1. /usr/local/bin is already in your PATH But not /usr/local/sbin, which I had to add anyway. 2. Tons of build scripts break Not that much anymore, and gems can now be configured much more easily thanks to bundler. It's indeed a chore to tell configure to link against this or that, but most of the time you just build a package anyway (trivial with pacman/abs) for things to be managed. 3. no need to worry about messing up existing tools. But many third party tools install stuff in /usr/local. Also, SIP prevents any mess from happening to system stuff. Also, regarding sudo: But do you trust the multi-megabyte Makefile that Homebrew runs? No I don't, that's why make/make install gets run as a regular user but under fakeroot when packaging with, say, pacman/abs. Running the install phase as root allows the package manager to make things just work, such as installing OpenVPN (which depends on tuntaposx kexts), or install daemons under their own user and have them launched on system boot (not user login) by /Library/LaunchDaemons, or install Python under /Library/Frameworks (which ironically, brew builds as a framework but stores somewhere else). Again, those are tradeoffs and it's good that a stance is taken either way. Disclaimer: long-time tentative maintainer of Arch OS X