Don't install homebrew in /home/homebrew, use /opt like we always do

[eabase]

Additional Info

• I am using Windows Subsystem for Linux

Output of brew config

n/a

Output of brew doctor

n/a

Description of issue

The issue is that you're breaking linux built-in security features by installing to a new "user" directory under /home. This make no sense at all, as it requires you to place read g/w readability to that directory.

This is abnormal AF, and is not even done on Macs.
Why is it not placed under /opt like we have always done for the last 30 years, when adding packages?

---

EDIT

I found this in the FAQ:

Why should I install Homebrew in the default location?

Homebrew’s pre-built binary packages (known as bottles) of many formulae can only be used if you install in the default installation prefix, otherwise they have to be built from source. Building from source takes a long time, is prone to failure, and is not supported. The default prefix is:

/opt/homebrew for macOS on Apple Silicon,
/usr/local for macOS on Intel, and
/home/linuxbrew/.linuxbrew for Linux.

Do yourself a favour and install to the default prefix so that you can use our pre-built binary packages. Pick another prefix at your peril!

Why is the default installation prefix /opt/homebrew on Apple Silicon?

The prefix /opt/homebrew was chosen to allow installations in /opt/homebrew for Apple Silicon and /usr/local for Rosetta 2 to coexist and use bottles.

Why is the default installation prefix /home/linuxbrew/.linuxbrew on Linux?

The prefix /home/linuxbrew/.linuxbrew was chosen to avoid writing to system-owned directories after installation while still allowing most precompiled binaries (bottles) to be used. Homebrew is designed for single-user installations rather than shared role accounts. See Support Tiers for unsupported multi-user environments.

---

However, the question still stands.

You still need root to write a new user directory under /home/something/
So you might as well, use root to create homebrew under /opt/homebrew and give that all rwx permissions.

It's really weird to have apps creating user directories, in addition, automated backups looks for user files, and don't wanna back up entire binary trees. In addition you're then putting it all inside a dotted sub-directory (.homebrew) for absolutely no reason at all. Anything ".dotted" is usally reserverd for configuration stuff, not for placing entire file/disk installaion trees. It was Microsft madmen that started doing this... Ruining any sensible file structure in their OS, then the madness propagated into Apple, and now also into Linux world.

Since you're already using /opt/homebrew for Apple Silicon, so why not extend it to the Linux distros?

This location issue is also the main reason why there are no compatible homebrew packages for linux.

[p-linnane]

A few things to address.

There are several thousand Homebrew packages (bottles) for Linux. You can confirm by running brew install <anything> on a supported distro and watching a precompiled binary download (if you're using the default prefix).

The prefix isn't chosen to avoid root at install time. It's to avoid root for every subsequent operation. The install directory is chown​ed to a user (the linuxbrew user by default), so brew install, brew upgrade, brew cleanup, etc. run unprivileged from then on. Same ownership model as /opt/homebrew on Apple silicon, just with the parent under /home so it lines up with how Linux distros expect non-root-writable trees to live.

On extending /opt/homebrew to Linux: the dominant constraint is bottle relocation. Bottles bake the install prefix into binary metadata (rpaths, embedded paths in scripts, .pc files, etc.). Changing the default prefix means rebuilding every bottle in homebrew-core. There's also the question of how we would move existing users to a new prefix. It's messy and not worth it.

The FAQ section you quoted already covers installing to a custom prefix if the default doesn't suit you, with the tradeoff that you'll build from source. That tradeoff exists precisely because of the bottle relocation issue above.

[Bo98]

For further context: the decision to even have /opt/homebrew on macOS came much later than Linux support did.

As for why /home/linuxbrew/.linuxbrew was chosen: Homebrew for Linux started off as a forked community project called Linuxbrew (hence the naming of /home/linuxbrew/.linuxbrew) and one of the driving use cases that some of the maintainers had for Linuxbrew even existing was the ability to install and use it on Linux boxes where they did not have any sudo permissions, otherwise you could just use the system package manager. Initially, this started off as being able to be installed in your own home directory (~/.linuxbrew) but this drifted to /home/linuxbrew/.linuxbrew specifically as precompiled bottles became the primary means of usage and relocation therefore became a problem.

If we were to develop Homebrew for Linux afresh today would we pick /opt/homebrew? Probably. Is it worth breaking everyone's installs and spending months rebuilding everything to move to it? Probably not.

[eabase]

Patrick, Bo
Thanks for your answers.

It's to avoid root for every subsequent operation.

If you set the correct flags on /opt/homebrew from the beginning, you never need to be root again.

Bottles bake the install prefix into binary metadata (rpaths, embedded paths in scripts, .pc files, etc.).

This is what's most concerning. Baking-in hardcoded paths into binaries is just so 1980's. Today it should be considered a never & no-go, at least as long as there is no config or env override available. Is there a way to check if a package is using hardcoded paths?

If this really becomes a problem I suppose one could also softlink the /opt/homebrew to /home/homebrew somehow, but I suspect the ./.homebrew would make it less trivial.

I'm doing some trials, using the /opt/homebrew, so let's see how that goes.

Clearly I'm new to Brew, so I really appreciate your patience and engagement.

[SMillerDev]

This is what's most concerning. Baking-in hardcoded paths into binaries is just so 1980's.

You're gonna be very disappointed to find out when most essential software was written. In addition to that, not all of those files are binaries.

Is there a way to check if a package is using hardcoded paths?

Yes, use something like otool tool list all the strings in binaries and libraries. And something like grep for plain text files.

[MikeMcQuaid]

Is there a way to check if a package is using hardcoded paths?

Note: we already do this. A package without hardcoded paths is marked cellar :any or cellar: :any_skip_relocation. This means it can be installed in any prefix and still work. You will notice that sadly the majority of packages are not. If we ever get 100% cellar :any or cellar: :any_skip_relocation: we'll let Homebrew be installed anywhere.

[krishkhinchi]

I think the main reason is that Homebrew intentionally avoids requiring ongoing root access on Linux.

Using /opt/homebrew would typically mean either:

• running brew commands with sudo, or
• making a system-owned directory user-writable

Both have their own security and maintenance tradeoffs.

/home/linuxbrew/.linuxbrew keeps everything user-controlled while still being in a predictable global location for bottles. The .linuxbrew part is mostly to avoid cluttering /home/linuxbrew directly.

That said, I do understand the concern about backup tools and filesystem conventions. On Linux, /opt definitely feels more natural for large software trees than a hidden directory under /home.