News for hackers. Stuff that matters.
Re:Homebrew 3.0 by shagie on Friday February 05, 2021 @10:01AM (#26036996)
MacPorts and Homebrew have a different philosophy of software installation.

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.

Re:Homebrew 3.0 by loeg on Friday February 05, 2021 @10:40AM (#26037479)
> 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.

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?"

Re:Homebrew 3.0 by banana_giraffe on Friday February 05, 2021 @12:41PM (#26038943)
> Homebrew wants you to change ownership of /usr/local to your individual user

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[@]}"
    fi
Re:Homebrew 3.0 by anaerobicover on Friday February 05, 2021 @01:35PM (#26039647)
Parent's information is outdated, but originally/historically Homebrew did want you to chown /usr/local
Re:Homebrew 3.0 by anaerobicover on Friday February 05, 2021 @04:28PM (#26041448)
Actually (I can't edit the original comment anymore) it looks like they were still recommending this as recently as last year?? https://discourse.brew.sh/t/permission-problems/3011/29

Haven't used Homebrew in quite a time, so I'm not sure.

Re:Homebrew 3.0 by loeg on Saturday February 06, 2021 @12:49PM (#26048287)
As recently as like, 1-3 months ago, yeah? I would have tried to install homebrew for the first time sometime December 2020 or later.
Re:Homebrew 3.0 by dylan604 on Friday February 05, 2021 @11:12AM (#26037838)
Huh? I'm on Big Sur running homebrew.

'ls -l /usr' reveals that /usr/local is root:wheel just like all other folders under /usr. How exactly is homebrew changing ownership?

Re:Homebrew 3.0 by loeg on Friday February 05, 2021 @11:23AM (#26037961)
Any chance you're on Apple Silicon? For some reason homebrew uses /usr/local on Intel macs and /opt/homebrew on ARM macs.

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.

Re:Homebrew 3.0 by djrogers on Friday February 05, 2021 @12:16PM (#26038618)
> Homebrew asks users (on Intel macs) to change the ownership of /usr/local to their local user.

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.

Re:Homebrew 3.0 by anaerobicover on Friday February 05, 2021 @12:56PM (#26039164)
This changed in the last few years (I don't recall the exact date), but it absolutely was the way that brew operated for many years.

https://apple.stackexchange.com/questions/1393/are-my-permis...

https://superuser.com/questions/1264673/chown-usr-local-oper...

Re:Homebrew 3.0 by dylan604 on Friday February 05, 2021 @11:38AM (#26038158)
>Any chance you're on Apple Silicon?

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.

Re:Homebrew 3.0 by Redoubts on Friday February 05, 2021 @12:55PM (#26039146)
https://stackoverflow.com/questions/16432071/how-to-fix-home...

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

Re:Homebrew 3.0 by ashtonkem on Friday February 05, 2021 @10:30AM (#26037363)
Given the moving nature of the OSX toolchain and directory structure, having your third party package manager integrated into the system toolchain increasingly feels like a bad idea.
Re:Homebrew 3.0 by shagie on Friday February 05, 2021 @01:33PM (#26039620)
The flip side of that is "do you want to have two scripting and compiler toolchains installed on the machine - one that gets updates from the vendor and one that gets updates from volunteers?"

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.

Re:Homebrew 3.0 by mojuba on Friday February 05, 2021 @10:18AM (#26037208)
Containers cover some use cases but not all. Experimentation for one, also if you need specific compiler toolchains that you occasionally use on your sources. You don't create a Docker image each time you need a specific toolchain. MacPorts definitely shines here but it's probably not a great option for non-technical users.