Hacker News Reader

Comment by vr46 | Hacker News Reader

Always good news to see progress in Brewland. I personally do not like having it installed in /usr/local and have ensured it never is on my installation, but I've not had the chance to ever discuss with one of their team why they do it and what things may possibly explode by not having Brew installed to /usr/local

View on HN

We put as much stuff as possible in `/usr/local/Homebrew` and `/usr/local/Cellar` now so hopefully that helps a bit. `/usr/local/bin` and friends are now mostly just symlinks. As mentioned in another comment, we've got some historical and current reasons for this location and build our binary packages (bottles) for there but you can install Homebrew in any location you want: https://github.com/Homebrew/brew/blob/master/docs/Installati...

Bottles are good. But I've never hit those other problems, while I have hit issues through using /usr/local.

Perhaps your release of Homebrew is better and safer than you expected? :D

For C libraries, having it in /usr/local is a benefit, since many already default to looking there, like cmake and autoconf scripts. Otherwise you have to fix that for many build scripts.

While I share your misgivings about sticking stuff like this at the "system" level, I think they are right to do so in this case, for simplicities sake.

/usr/local is explicitly for user/administrator managed software versus /usr being for system managed stuff, it's the correct location for this on any UNIX/POSIX-like system.

Yes, sure, but there's always been a presumption in those definitions that you have a multi-user system. I would say that most people today operate their computers as single users. The multiuser paradigm, is more about differing security contexts.

For me these locations are an artifact of multiuser systems days, it's generally more desirable for me to store most stuff in my home directory, such that when I upgrade computers, there's only one thing to copy over.

Having brew install to ~user would be grand, not just for portability, but also to isolate it across users.

I do this. It's simple enough to install homebrew, to, say, $HOME/.homebrew. I haven't had any problems with this approach, but then, I don't use Ruby, and if I did I wouldn't use homebrew to manage it.

Except when you run Homebrew?

I mean, I understood you, I'm fairly sure brew is the only Ruby command I run on a regular basis...

Right, true.

We can't relocate many binary packages (bottles) with dynamic paths like that, unfortunately, or we'd do that.

The multiuser features are used to provide defense in depth, especially for developer machines.

Apple's migration tool and cloning have always worked for me.

> POSIX

Annoyingly, the FHS isn't POSIX (nor SUS) and thus not Unix. There's thus no real standardisation on what the filesystem should look like and thus even Guix or Gobolinux can be POSIX candidates.

Even macOS takes advantage of this nonstandardisation by putting stuff in /Applications, /Library and /Users.

The debate about what belongs in /usr, /usr/local, /opt (and hahaha, /opt/local) is mostly subjective opinions about just how local these local things are.

One of the issues I recall comes from not using Homebrew exclusively. For example, installing GPG from package puts files in the same location, and I've had conflicts in the past. It's not always possible to use Homebrew exclusively, so I move it elsewhere to mitigate this possible problem.

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...

The 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

Where do you have it installed instead?

$HOME/.homebrew

Reply on news.ycombinator.com