Hacker News Reader

Comment by rswail | Hacker News Reader

The majority of the ports and software I want installed are essentially Unix/Linux/GNU environment tools.

Macports has always seemed to me to be a more "unix-y" way of doing that, and it works politely with Apple's ways on top of the Unix core (eg locking down the system volume).

It also has a very nice "select" and "variants" system that allows you to have multiple versions of a package as well as packages with more or less functionality (eg integrating with the MacOS keychain etc).

When I first got into Macs (only around 5 years ago), I looked at both homebrew and macports and as soon as I saw homebrew blasting stuff into /usr/local while macports neatly put everything in /opt, I was convinced to go with macports. I also had previous experience with the BSD's port systems, which helped push me towards macports.

But I'm open to being convinced about homebrew, although I've never needed something that it had that macports didnt.

View on HN

I used to recommend Homebrew but stopped some time ago (v2, perhaps?) when they hard-removed all build customization/options in order to make it easier to develop bottles and close out GitHub issues (on their end) while severely restricting what users could do, taking away a lot of power and freedom that was previously available. Much more inline with the Apple line of thinking, but that’s kind of the reason people wanted a *nix-esque package manager, no?

Why is it bad that homebrew puts files in /usr/local?

Edit: They use /opt if you're on Apple Silicon https://github.com/Homebrew/brew/blob/master/docs/Installati...

There's nothing wrong with installing packages into /usr/local, but brew turns /usr/local into a git repository and IMO that is wrong. Also, brew acts like it's made for a single user, as it changes files and directories to be owned by the user running it, but /usr/local is a system directory. When I install brew, I always put it into my home directory instead of /usr/local.

It turns /usr/local/Homebrew into a git repository; not /usr/local itself. Whatever it links into /usr/local/{bin,include,lib,sbin,share} is just a symlink into /usr/local/Cellar.

Are you sure about that? I currently have it installed in ~/brew and commands link from ~/brew/Cellar into ~/brew/bin and there is a .git directory in ~/brew. I used to put it in /usr/local and it irked me that there was a /usr/local/.git. That was the main reason I stopped putting it there.

They used to put the repo in /user/local but moved it to /usr/local/Homebrew a few years ago.

Yes, I'm sure, it exactly like that on this very machine where I type this comment. However, the Apple Silicon version installed into /opt/homebrew creates the repo directly in its prefix, just like yours installed into ~/brew. Here the content of Homebrew dir is mixed with Cellar, Frameworks and Caskroom, which are normally one directory up. So it looks like it behaves differently when the prefix is /usr/local.

It used to turn /usr/local into a Git repository, at least until that got locked down with SIP.

While /usr is locked down with SIP, /usr/local is not, it is perfectly writable; brew does create new directories there and changes ownership of existing ones.

How's the experience putting it under your home? I assume many packages need to be compiled but does everything compile fine?

I'm upgrading right now on Big Sur, and everything was installed from pre-built binaries; nothing was compiled locally.

I've never had an issue with it. I just add ~/brew/bin to my PATH and everything works fine.

My first experience with homebrew (as a non-mac user) was setting up a build agent a few years ago. It seemed like a nice way to get everything going, as well as being analogous to the ways it was setup on other OSes (using packages to manage the SDKs/tooling).

I think my mistake was treating it like any other unix-y [multi-user] system, because I installed everything with one account, then created a dedicated 'build' account for the agent to run as -- exactly as our linux (and even, ahem, Windows) agents were setup. This caused all kinds of failures for the 'build' user as everything was owned by and had permissions setup for the first user.

I came away kind of disgusted at the horrible patterns in use. Windows has spent two decades cleaning up that mistake, and here's a comparably new system making the same, awful mistakes?

User-writable/owned stuff goes in ~. Period.

/usr/local was originally for local (ie host) software that wasn't in /usr/{bin,lib,sbin,slib...} or /{bin,lib,sbin,slib...}.

Then GNU took over and made some opinionated choices about how those subdirectories were to be used, which is fine.

However, because /usr/local is under /usr, it meant that it was more difficult to mount /usr as read-only or shared. There is also the issue of whether files under /usr/local should be owned by non-system users.

A while back, the creation of /opt and /opt/{some-app} (and /var/opt/{some-app} became a way to avoid writing into /usr and also made it possible to mount applications with their code as read only with writable locations under /var.

So I've taken writing to /usr/local as a packaging smell these days, purely to avoid writing into /usr.

Reply on news.ycombinator.com