> Homebrew, on the other hand, uses the system toolchain and tries to avoid using root.
What? Homebrew wants you to change ownership of /usr/local to your individual user and refuses to run without doing so. How is that any different as far "as all users on the system share the same software?"
If I read homebrew's install.sh correctly, it changes ownership of a few directories under /usr/local, not /usr/local itself (on x86, on ARM it follows a different path). This matches how my current Mac, which has brew, is currently setup as well.
# Required installation paths. To install elsewhere (which is unsupported)
# you can untar https://github.com/Homebrew/brew/tarball/master
# anywhere you like.
...
# On Intel macOS, this script installs to /usr/local only
HOMEBREW_PREFIX="/usr/local"
...
directories=(bin etc include lib sbin share opt var
Frameworks
etc/bash_completion.d lib/pkgconfig
share/aclocal share/doc share/info share/locale share/man
share/man/man1 share/man/man2 share/man/man3 share/man/man4
share/man/man5 share/man/man6 share/man/man7 share/man/man8
var/log var/homebrew var/homebrew/linked
bin/brew)
group_chmods=()
for dir in "${directories[@]}"; do
if exists_but_not_writable "${HOMEBREW_PREFIX}/${dir}"; then
group_chmods+=("${HOMEBREW_PREFIX}/${dir}")
fi
done
... and further on, after some checks, group_chmods turns into chowns ...
if [[ "${#chowns[@]}" -gt 0 ]]; then
ohai "The following existing directories will have their owner set to ${tty_underline}${USER}${tty_reset}:"
printf "%s\n" "${chowns[@]}"
fiHaven't used Homebrew in quite a time, so I'm not sure.
'ls -l /usr' reveals that /usr/local is root:wheel just like all other folders under /usr. How exactly is homebrew changing ownership?
Anyway, this requirement is well documented and not new:
https://github.com/Homebrew/brew/issues?q=is%3Aissue+%2Fusr%...
http://github.com/Homebrew/brew/blob/master/docs/Installatio...
Homebrew asks users (on Intel macs) to change the ownership of /usr/local to their local user. And it refuses to run under sudo.
Nope - intel Mac on Big Sur:
drogers@SJCMACJDYMD6M ~ % ls -l /usr
[snip]
drwxr-xr-x 15 root wheel 480 Dec 14 20:10 local
[end snip]
And for the record, neither of your links support your claim.
https://apple.stackexchange.com/questions/1393/are-my-permis...
https://superuser.com/questions/1264673/chown-usr-local-oper...
No, I'm on an Intel chip, not M1.
>Homebrew asks users (on Intel macs) to change the ownership of /usr/local to their local user. And it refuses to run under sudo.
Again, no, not on my machine it doesn't. /usr/local is root:wheel. This is a newish (to me) machine that I gave first birthday to beginning of December 2020. The first thing I did was installed brew and started installing the things that makes my computer useful to me. No permissions were asked to be changed.
Dunno if it needs this now anymore -- i think they moved to /usr/local/Homebrew some time ago -- but this was a big deal for a few years
The spot where this becomes an issue would be say... (making up a story here) there's a vulnerability found in Ruby which is part of the toolchain for the system and in MacPorts toolchain. Apple pushes out a security update that updates the system toolchain... but the issue in the MacPorts toolchain remains until that is updated.
I had an issue with MacPorts many years ago when I was trying to install a python library via MacPorts (I forget exactly why) but wasn't being found with python on the command line (which was using the system toolchain) and then when I resolved the "I'm using the MacPorts version on the command line" other issues with software that was expecting the system toolchain version started cropping up.
That's a "my experience" story and isn't meant to be defining.
I believe that both Homebrew and MacPorts have made design choices that reflect how they want to take their respective projects and I respect those design choices. They solve problems in different ways and have different repercussions for how users use them.
For me, on my systems, I've found that I tend to prefer to fix the problems that Homebrew causes than the problems that MacPorts causes. The big thing that made that preferable is that the services (databases and such) are not run on the bare machine but rather in containers.
MacPorts wants to have its own thing over in /opt where it has its own toolchain independent from the system tool chain.
This means that all users on the system share the same MacPorts software. This has an additional impact that it means that it requires privilege to install software there.
Homebrew, on the other hand, uses the system toolchain and tries to avoid using root.
In today's world, the "multiple versions of complex products like PHP or MySQL at once" isn't a compelling argument for me as I use docker to solve that problem.