The sad part is that /usr was supposed to be the original Unix user home directories.
/bin was where you kept your binaries, and /lib for your libraries.
El Capitan and Homebrew
251–260 of 298 posts
Re: El Capitan and Homebrew
#252Earlier 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.
That's very clever. There is one problem though, now make clean all install is run as root (well maybe install stages now in homebrew). Imagine an env var not set (the way make vars interact give lots of way to shoot off a big toe here) and the wrong dir gets rm_-rf_-ed or it obliterates something in /bin instead.
If you don't run brew as root you at least protect places like /usr/lib, but you are protected from that and more with macports (where stages and uses nobody).
But for now your approach seems the best pragmatic course to take, thank you for the suggestion.
Re: El Capitan and Homebrew
#253Shit 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…
I'm not totally sure how exploding batteries and optional OS upgrades are driving you forward through planned obsolescence. I feel like maybe in your apparent "rage" you lost the logic thread of the point you actually wanted to make and conflated a few things into an incoherent rant.
Re: El Capitan and Homebrew
#254This didn't work for me. Upon 3rd bullet point 'Reboot back into OS X' my system kept showing me the apple logo, black background and status bar. When the status bar progressed ~30%, information about my system would popup and then stagnate/momentarily freeze. Then the system would go to black saying 'os had a problem, rebooting in a few seconds' then...it would repeat this process again and again, without any input…
Maybe clear your kext cache. Also boot it single user mode so you can see where it fails.
Re: El Capitan and Homebrew
#255Earlier quoted context omitted.
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?
The command line tools package includes all you need to compile with and is far smaller than Xcode. I think it's about 150mb.
Re: El Capitan and Homebrew
#256Earlier quoted context omitted.
And I contend that homebrew did not want to used ~/.homebrew because that would mean modifying files to add it to PATH and be additional testing for people that write recipes.
And that's totally fine, and I let Homebrew own /usr/local too. What I'm not going to do is freak out when a totally sane and useful security feature breaks that install mode, especially when I could, if I cared that much about convenience, just take 30 seconds to disable the security feature.
I just want to make clear I'm not freaking out (and I know you're not either).
I would hope though that out of this someone would think, "Hmm... oh drat... yeah I guess this is just one of those things that nobody predicted at first. Shot I think it was a bad idea to have a user own /usr/local/. But you know, it's a good time to improve things... hmm... I know let's build and stage as nobody and then copy under /usr/local/! We still can have binary packages always work and nobody has to mess with PATH, man pages, or dynamic linker trivia. We might have to write something though that asks for a username and password, but whoa... OSX makes that surprisingly easy... I should do that!"
It's not going to be me cause I don't use homebrew, but that would be way better than these hacks that will ammount to people being encouraged to just disable SIP cause of the headache after ever software update.
Re: El Capitan and Homebrew
#257Earlier quoted context omitted.
No, /usr/local is normally 755 root:root (or whatever the effective equivalent is). Homebrew wants it to be 775 root:admin, so that users with the admin bit can write to it. That's not standard. People keep writing here as if El Cap removes /usr/local entirely. It does not. /usr/local is there by default. You only have to go into recovery mode if you've somehow removed it yourself.
quesera's reply points-out just how bad it is, but even for just 775 root:admin I would have to use sudo (plus edit the sudoers or /usr/bin/login -p first) anyway: $ /usr/bin/env -i /bin/sh -c \ 'id | grep -lw admin >/dev/null && echo admin || echo non-admin' non-admin The problem is I have no problem using sudo, but homebrew does (like it wants make all to happen as me).
Yeah, the more I read this thread, the more I'm thinking "why is that?" - `apt-get` et al have no problem with you using sudo, why does `brew` scare you into an alternative? 'because Mac'?
Re: El Capitan and Homebrew
#258To be fair, homebrew shouldn't need to change perms, it should follow common unix standards or at least fit in with OSX rather than require a hack. For years I've felt homebrew should really use either /opt/ or ~/.homebrew/ by default.
If I have already installed a bunch of packages, how do I move everything to something like ~/.homebrew? (1) Change the HOMEBREW_PREFIX (2) move the existing aliases from /usr/local/bin (3) add the directory to my path (4) ???
Re: El Capitan and Homebrew
#259Earlier quoted context omitted.
Don't many of the dev command line tools, like clang, come from xcode?
The command line tools package includes all you need to compile with and is far smaller than Xcode. I think it's about 150mb.
Yes, that's true, and of course that's what I'd like to do (command line tools only), but last time through that was yet another ten minutes to find the correct xcode and match things up and so on ...
I fully accept that I'm just being a complainer here, but in answer to the parents question, those are the mental blocks for me.
Re: El Capitan and Homebrew
#260Earlier quoted context omitted.
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
Yes, that is exactly what I did. It still took forever to find the right Google keywords to find what I needed, and figure out the right command line invocations. And I would need to re-learn it all over if I ever upgraded SDL. By comparison, downloading the pre-packaged binaries from LibSDL.org takes all of 10 seconds...
You should also look at otool as well while you're at it. They're useful commands, just difficult to discover unless you already know what you're looking for.