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

231–240 of 298 posts

Re: El Capitan and Homebrew

#231

Post by msbarnett »

osxrand wrote: post #193
matwood wrote: post #189

Earlier quoted context omitted.

> 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.

I can confirm that /usr/local is there by default on a clean install of El Capitan

Re: El Capitan and Homebrew

#232

Post by teacup50 »

msbarnett wrote: post #226
joshmoz wrote: post #172

Earlier quoted context omitted.

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…

For a while at least, when Homebrew was getting popular, MacPorts seemed highly moribund and destined to be abandoned. It seems to have recovered some life since then, though. Homebrew got big in the ruby community first -- I distinctly remember trying to get Rails to work with MacPorts' MySQL install and the whole thing turning into a clusterfuck, and then someone introducing me to homebrew where the whole thing jus…

Nothing really changed in terms of MacPorts liveliness; development continued as it always had, and Homebrew has gradually learned why MacPorts adopted the solutions it did -- usually the hard way.

Homebrew's popularity was built on incredibly negative (and often dishonest) marketing that painted MacPorts as old and busted.

For example, Homebrew touted the security advantages of not using sudo, as compared to MacPorts, ignoring the fact that:

1) MacPorts dropped privileges when performing port builds to an unprivileged user, providing generally higher security than running with the current user's full permissions.

2) MacPorts has always also supported non-root installations that didn't require sudo.

Re: El Capitan and Homebrew

#233

Post by snowwrestler »

OJFord wrote: post #199
snowwrestler wrote: post #155

Earlier quoted context omitted.

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?

So that Homebrew always requires my password to install an app, just like native OS X installs. It also preserves the default permissions. And it's not that hard to sudo.

Re: El Capitan and Homebrew

#234

Post by aorth »

urda wrote: post #220
rolux wrote: post #18

How to disable SIP altogether: http://arstechnica.com/apple/2015/09/os-x-10-11-el-capitan-t...

Much like 'goto' statements in code, unless you really have a good reason to do you shouldn't disable SIP.

Every time you disable SIP ... a kitten dies? Related, stop disabling SELinux!

http://stopdisablingselinux.com/

Re: El Capitan and Homebrew

#235

Post by spinlock »

tvon wrote: post #149
lectrick wrote: post #136

It does kind of make sense to me that user-owned things should kind of live in /Users/username. Unfortunately that pattern in this case would lead to the redundant-seeming /Users/username/usr/local, but at least that's rooted to the user in the event other users don't want a "global" Homebrew install. Also, I believe (even if it kills some ignorant build scripts) that Homebrew lets you reconfigure where this director…

Homebrew can be installed anywhere, and after ~2 years of having it outside of /usr/local I have not run into any problems. There is a disclaimer somewhere that states some "packages" may not work well with this setup, but that seems like an upstream bug to me. Things should not require things to live in a specific path or prefix.

Where does your homebrew live? I have a few different users on my mac that I want to all share resources so I've kept it in /usr/local (also the "easiest" because it was the default).

TBH, things like this make me really mis debian. It's really nice when your package manager is a first class citizen (and geared towards software development rather than consumption).

Re: El Capitan and Homebrew

#236

Post by mzs »

eslaught wrote: post #230
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…

I realize this is anecdotal, but my experience has been much more like robbles' than mapgrep's. One issue is that the MacPorts built versions of things don't always integrate in a nice way with other parts of the system. For example, it used to be the case (and may still be) that LibSDL built under MacPorts would hard-code the absolute build path used to build it into the shared object, so that the frameworks wouldn'…

There used to be nice documentation online about frameworks but from that I learned:

$ man install_name_tool

Edit: I looked in one of my Makefiles:

  install_name_tool -change \
    /bar/baz/lib/libfoo.7.dylib @executable_path/lib/libfoo.7.dylib a.out

Re: El Capitan and Homebrew

#237

Post by mzs »

mmastrac wrote: post #177
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…

Ditto. And Homebrew's policy of avoiding installation of built-in packages by default means that you don't accidentally break your whole system when MacPorts shadows a critical core package.

Run otool to check but Apple at least builds their stuff right and it's getting harder for companies to shoot themselves in the foot like that cause Xcode automatically does the right stuff for devs that are rushed not careful.

Re: El Capitan and Homebrew

#238

Post by mzs »

npongratz wrote: post #201
joshmoz wrote: post #172

Earlier quoted context omitted.

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…

I'd advise caution doing an `rm -r /opt`, and suggest it might be more precise (and generally better) to `rm -r /opt/local`. Macports will typically install to /opt/local, and in my experience, stuff like vagrant and certain VPN clients will install into subdirectories of /opt.

In fact there was a version of Cisco VPN client that blew away /opt (and all of my macports) on first install!

Re: El Capitan and Homebrew

#239

Post by omegote »

eggie wrote: post #128
omegote wrote: post #101

Shit like this happens everyday and yet many regard OS X as the best development platform. Wtf?

You could have a stable free environment that will work for a decade or a proprietary one that's designed to cause older computers to break and require expensive upgrades. For various reasons many people love the latter. I also don't mind having excuses to upgrade my hardware but I dislike being driven forward by planned obsolescence, which is basically how every piece of Apple hardware I've ever owned has ended its…

+1, and yet my post got downvoted to oblivion, lol. I'm sorry I bothered all those developers at starbucks with their macbooks and their hard-to-prononunce coffees.

Re: El Capitan and Homebrew

#240

Post by nomel »

Scarbutt wrote: post #223
mapgrep wrote: post #214

Earlier quoted context omitted.

Just FYI anyone can download XCode from the App Store, it doesn't require a "dev login". (Agree it would be nice if MacPorts only required the XCode Command Line tools like homebrew, it would be one less download.)

I was going to try macports but the XCode download turn me off, why it can rely only on the command line tools?

Don't many of the dev command line tools, like clang, come from xcode?
Post reply on HN