Linux install with fixed user?!

[nerdoc]

Additional Info

• I am using Windows Subsystem for Linux

Output of brew config

n.a. (can't install brew)

Output of brew doctor

n.a. (can't install brew)

Description of issue

I'd like to install Homwbrew on linux, and am using the recommended install method by openclaw:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

This fails, because the Howmebrew install script tries to install into fixed /home/linuxbrew/.linuxbrew:

Insufficient permissions to install Homebrew to "/home/linuxbrew/.linuxbrew" (the default prefix).

This seems not correct to me, as lines below the issue in https://github.com/Homebrew/install/blob/5838cadbb2c7beb17c7dcdddb5f0dba6c4780feb/install.sh#L185C1-L187C43 there is a reference to $HOME.

So why is there a fixed prefix to the "linuxbrew" user, while you could be operating on any user? Even if the user linuxbrew exists, I would not have access to his $HOME directory.

Is this a bug, or did I miss something. Could not find a discussion about that here, nor any documentation. (Maybe I searched too short?)

[p-linnane]

/home/linuxbrew/.linuxbrew is the intentional default prefix for Homebrew on Linux. It's not a reference to a user's home directory. This path was chosen so installations can be shared across multiple users on a system with a consistent, predictable prefix.

The $HOME reference you noticed on line 187 is for the cache directory ($HOME/.cache/Homebrew), not the installation prefix.

[nerdoc]

IMHO this is extremely misleading. I am an experienced Linux user, but was completely disturbed by the fact that something is installed in /home/linuxbrew. This is simply not the directory where it should be installed - look at the OSX install - you install it into /opt/homebrew there - this is exactly where I would expect it to be under Linux too.
Additionally, IF there exists a user named "linuxbrew", everything gets screwed up.

So, why don't you simply change the install path to /opt/linuxbrew? Is there something that speaks against that clean solution?

[SMillerDev]

Yes, a lot of Linux users of Homebrew can't install in system paths because those are locked down. You might get the IT team to create you a home directory to manage, chances are approaching zero they let you manage something in /opt.

[nerdoc]

I don't understand. You have to install Homebrew with root anyway, so you have access to /opt.
So this is basically a "workaround" because some users can't access /opt (because it is on another disk/mount point) and managed by the "IT team"?
Imagine you have multiple users, then /home/homebrew needs to have 777 permissions (or at least 770 with users group).
I really can't get the point: If you have root access (which you need for homebrew), what hinders you accessing /opt?
If you need a certain directory that is not "system" like /opt, and you need the "IT team" to "create you a home directory to manage" - meaning /home/linuxbrew, you need write permissions there. Why can't you install homebrew then as local user in YOUR home directory.

What exactly do you mean with "because those are locked down"?

[p-linnane]

The error you're seeing is expected behaviour. The install script checks for sudo access and exits if it can't get the permissions needed to create /home/linuxbrew/.linuxbrew. This isn't a bug with the prefix choice, it's a permissions issue on your system.

To install Homebrew on Linux you need either sudo rights, or an admin to pre-create /home/linuxbrew/.linuxbrew with appropriate permissions for your user. It's also worth noting that all of our bottles are built against that prefix, so using a different one means compiling everything from source.

[nerdoc]

Hm. Don't agree. While the permission check does e.g. not work when you (e.g. temporarily) allow a user NOPASSWD access per visudo under linux (just put the line <your_user> ALL=(ALL) NOPASSWD: ALL into your /etc/sudoers file and call the Homebrew installer. it will ask you for your password despite having rights to run all commands using sudo without passwords. Use case: I don't want to know my user's password, I just want it to install homebrew. root can't install homebrew. and normal users need sudo rights. but not with NOPASSWD...)

But the main thing is: I am questioning the design of Homebrew here. You may find this decision normal because you are used to it for a long time. But this doesn't mean it's a good design. I am just giving feedback as an external person who tries to install Homebrew the first time and comes across a few problems - and I think they are worth reporting.

Because, think what you want, but /home under Linux, /Users under MacOS is the home base directory of users. /opt is the directory for optional software that is installed sideways/alongside the packaging system. On both systems.

And there is no reason IMHO to put a software into /opt on OSX and into /home/linuxbrew on Linux, as I explained before.
What do you do if a user "linuxbrew" exists?

Even worse. If you install Homebrew as user "nerdoc" (with sudo etc). You'll get a /home/linuxbrew/.linuxbrew directory that is owned by "ǹerdoc", with 755 permissions:

ls -la /home/linuxbrew/.linuxbrew
insgesamt 56
drwxr-xr-x 14 openclaw openclaw 4096 17. Feb 19:26 .
drwxr-xr-x  3 root     root     4096 17. Feb 19:26 ..
drwxrwxr-x  2 ǹerdoc ǹerdoc 4096 17. Feb 19:27 bin
drwxrwxr-x  2 ǹerdoc ǹerdoc 4096 17. Feb 19:26 Caskroom
drwxrwxr-x  2 ǹerdoc ǹerdoc 4096 17. Feb 19:26 Cellar
drwxrwxr-x  3 ǹerdoc ǹerdoc 4096 17. Feb 19:28 etc
drwxrwxr-x  2 ǹerdoc ǹerdoc 4096 17. Feb 19:26 Frameworks
drwxr-xr-x 15 ǹerdoc ǹerdoc 4096 17. Feb 19:27 Homebrew
drwxrwxr-x  2 ǹerdoc ǹerdoc 4096 17. Feb 19:26 include
drwxrwxr-x  2 ǹerdoc ǹerdoc 4096 17. Feb 19:26 lib
drwxrwxr-x  2 ǹerdoc ǹerdoc 4096 17. Feb 19:26 opt
drwxrwxr-x  2 ǹerdoc ǹerdoc 4096 17. Feb 19:26 sbin
drwxrwxr-x  6 ǹerdoc ǹerdoc 4096 17. Feb 19:28 share
drwxrwxr-x  3 ǹerdoc ǹerdoc 4096 17. Feb 19:26 var

Which is fine for a one user system. But with multi users, you might get problems.

I just can't see the real argument why it is not done in /opt as root, - or in $HOME, as <your_user>.
Maybe you could explain which problems users have with "locked down" /opt dirs.