Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

El Capitan and Homebrew

github.com

Post reply on HN
Print view View original

191–200 of 298 posts

Re: El Capitan and Homebrew

#191

Post by tomphoolery »

mapgrep wrote: post #180
robbles wrote: post #173

Earlier quoted context omitted.

The reason I switched to HomeBrew, after attempting to use MacPorts for several years, was that the formulas all actually worked and resulted in installations that weren't horribly broken and/or reliant on 10 different additions to my PATH and environment variables. Homebrew may have some questionable policies, but at least it works well and has recipes that successfully compile. It also tells you why recipes aren't…

> reliant on 10 different additions to my PATH and environment variables MacPorts adds exactly two directories to the $PATH: export PATH=/opt/local/bin:/opt/local/sbin:$PATH No new environment variables are added. The only required environment variable tweak is the PATH one above. (In a corner case, where you have modified your MANPATH in your bash profile, which almost no one does, you may want to add another variab…

Having both of those directories in your $PATH would definitely cause problems, you're loading two different collections of installed ports at the same time.

Re: El Capitan and Homebrew

#192

Post by mjs »

Steuard wrote: post #148
emanuelev wrote: post #92

Earlier quoted context omitted.

I can't think of anything more standard than /usr/local/.

It's been a while since I looked into it, but I opted to stick with MacPorts rather than Homebrew in large part because I got the impression that Homebrew wanted to own /usr/local rather than sharing it with other software. (Maybe that's inaccurate?) I still occasionally compile software by hand rather than through a package manager, and /usr/local has been the default target for a system-wide install on every Unix-s…

> I got the impression that Homebrew wanted to own /usr/local rather than sharing it with other software

This is still accurate. Homebrew creates/manages /usr/local/.git. /usr/local/.gitignore starts with /* which is … not conventional.

Re: El Capitan and Homebrew

#193

Post by osxrand »

matwood wrote: post #189
cdonnellytx wrote: post #174

Earlier quoted context omitted.

The problem is even _root_ can't add the missing /usr/local, because SIP prevents even root from touching /usr. SIP doesn't block /opt; if it did, MacPorts would also have broken, sudo or no sudo.

> The problem is even _root_ can't add the missing /usr/local, because SIP prevents even root from touching /usr. This goes against all that I have read and my own experiences with the betas. Maybe Apple changed something last minute. See here: http://www.macworld.com/article/2948140/os-x/private-i-el-ca... The specifics of System Integrity Protection are that no user, application, or process will be able to write fi…

The bit you quoted doesn't contradict what the OP stated, if /usr/local _does not_ exist, not even root can create it.

If it exists, we can use it as before.

Considering how many times I've installed OS X, I can't recall if /usr/local is there by default (excluding 10.11 for the moment). Will have to do another few installs and check.

Re: El Capitan and Homebrew

#194

Post by tptacek »

DannyBee wrote: post #152
quesera wrote: post #141

Earlier quoted context omitted.

BSD and Linux use /usr/local, it's not universal. But /usr/local has never been writable by non-privileged users. Homebrew depends on that nonstandard and undesireable permissions model. Apple doesn't bend to accommodate an inappropriate use. Hombrew doesn't want to use a location that is outside the default PATH, and they don't want to install with proper permissions, so they purposefully misinterpret the "standard"…

A. There is no real standard here B. Apple doesn't bend, period. They don't actually care whether the use is appropriate or inappropriate. C. Blaming this on homebrew is hilarious Remind me again why i should need to reboot into recovery mode to create a directory?

You need to boot into recovery mode to create /usr/local (or to disable SIP altogether) because /usr is immutable, so that code executing under an admin account can't inject itself into binaries (or into PATHs) under /usr.

I use Homebrew and will probably keep doing that because Homebrew is really convenient and just generally works better than MacPorts for me, but what Homebrew is demanding --- ownership over /usr/local --- is not in fact reasonable. It makes a lot of sense to me that OSX will want to keep perms on /usr/local (which is in everyone's PATH) locked down, and so it seems extra hacky that they're going to add a 'brew doctor' check to see if Software Update has "broken" those privileges.

The commenter upthread that suggested Homebrew should use ~/.homebrew or something by default is right.

Re: El Capitan and Homebrew

#195

Post by mapgrep »

tomphoolery wrote: post #191
mapgrep wrote: post #180

Earlier quoted context omitted.

> reliant on 10 different additions to my PATH and environment variables MacPorts adds exactly two directories to the $PATH: export PATH=/opt/local/bin:/opt/local/sbin:$PATH No new environment variables are added. The only required environment variable tweak is the PATH one above. (In a corner case, where you have modified your MANPATH in your bash profile, which almost no one does, you may want to add another variab…

Having both of those directories in your $PATH would definitely cause problems, you're loading two different collections of installed ports at the same time.

Not clear on your meaning. The fact that the two directories have completely different ports inside of them is the reason you want to add both to the PATH.

The line I pasted, from my own .bash_profile, is identical to the recommended approach: https://guide.macports.org/chunked/installing.shell.html

Re: El Capitan and Homebrew

#196

Post by tptacek »

lsaferite wrote: post #107
lsaferite wrote: post #104

Earlier quoted context omitted.

A simple 'sudo mkdir /usr/local' won't work with SIP?

Wow... I just re-read the page and saw what you have to do to create /usr/local and that is insane. Reboot into recovery mode?!? W.T.F?

"T.F." is that /usr is immutable under SIP, so if you somehow manage to nuke /usr/local, you have to disable it to put it back.

This is a good feature, and it's not a new one: the BSDs have done it for over a decade with securelevels and immutable mounts --- where you also had to take the system down to make alterations.

If you think about it for a second, you'll see that anything that would have allowed you, a normal user typing at the keyboard, to create directories under /usr would probably render the security of SIP meaningless. It's the fact that you do have to go into recovery mode to hack up your filesystem that indicates that there's actually a meaningful security check happening here.

Just think of SIP's filesystem protections as literally just being "you have to boot the system into a special mode to change certain parts of the filesystem". I want that feature, and I hack up my filesystem all the time! The overwhelming majority of Mac users don't even know they want the feature and benefit enormously from it regardless. A major win.

Re: El Capitan and Homebrew

#197

Post by tptacek »

DannyBee wrote: post #168
quesera wrote: post #164

Earlier quoted context omitted.

A. /usr/local has never ever been writable by a nonprivileged user. Every standard that exists, including the principle of least surprise, is emphatic on that point. The security implications of "any other way" are massive. B. If Linus or the FHS changed their ways in this, there would be outrage. It's inappropriate and just plain dumb. [edit: I shouldn't have said "dumb", please replace with "in violation of all gua…

A. Single user systems are not the same as server systems, and plenty of single user systems have had the equivalent of /usr/local as writable. If you want to argue this security is worth it, that's a different argument. I suspect most people who just want to get shit done are going to find it a huge pain in the ass. You can also argue these people are stupid. As for standards, vendors follow FHS and friends exactly…

The "single user systems aren't the same as server systems" argument cuts both ways. It is also not a big deal to reboot a single-user systems.

Re: El Capitan and Homebrew

#198

Post by [deleted] »

pjmlp wrote: post #131
baldfat wrote: post #98

Earlier quoted context omitted.

> certainly isn't a 'common unix standard' Here I google.com it for you. http://www.pathname.com/fhs/pub/fhs-2.3.html#THEUSRHIERARCHY EDIT: Why is it okay to NOT look up a Standard and be uncertain in your comments when it can be found in 20 seconds tops on the Internet?

Filesystem Hierarchy Standard is a GNU/Linux standard. 'common unix standard' is whatever POSIX states as standard.

[deleted]

Re: El Capitan and Homebrew

#199

Post by OJFord »

snowwrestler wrote: post #155
sambe wrote: post #143

Earlier quoted context omitted.

It doesn't take ownership by default IIRC - just recommends that you do so. It will work with sudo if you want to go that way.

I run my Mac with a non-admin account. When I want to install or update Homebrew applications, I su to my admin account and use sudo. Just checked my /usr/local and it's owned by root. I've never had a problem running Homebrew apps from my non-admin account.

This sounds like the best suggestion/solution in this thread. But if you run brew from admin, why can't admin take ownership , and run brew without sudo?

Re: El Capitan and Homebrew

#200

Post by rsync »

joshmoz wrote: post #172
mapgrep wrote: post #163

Macports, meanwhile, continues to work quite well because it 1. places packages in /opt and 2. has always installed via sudo. Macports just has a much more robust philosophy of building its own universe largely separate from OS X, and only rarely impacted by system updates. The downside is that it takes forever to install the first few packages. Homebrew offers a much faster initial install because it leans on OS X l…

Agreed, I don't understand why so many people use homebrew instead of macports. Macports seems to be immune to so many issues that complicate homebrew, and I love that it keeps everything in its own dir, '/opt'. Easy to see what it installed, and easy to uninstall (rm -r /opt). The commands are also easier for me to remember -- no awkward, overstretched analogy. I often help people start hacking on open source projec…

"Agreed, I don't understand why so many people use homebrew instead of macports."

This might seem very odd to you, and maybe I'm a weird outlier, but after having used macports for years, and installed it many times on many different systems, the requirement for full blown xcode is quite a turn-off and makes any alternative interesting and attractive.

The OSX system I am typing on now should have macports on it, and I sort of need it, but I just never have time to devote an hour to app store -> dev login -> xcode install -> blah blah -> macports.

Post reply on HN