221–230 of 298 posts
To 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.
I can't think of anything more standard than /usr/local/.
I'm now using /usr/local/bin.
I looked for a guide, no joy. The more opinionated, the better, because I just want to follow the norm.
Earlier quoted context omitted.
I think the bigger headache will be the next time you buy a new Macbook with El Capitan or later installed on it, because you'll need to do a song and dance to create the /usr/local directory in the first place.
A simple 'sudo mkdir /usr/local' won't work with SIP?
Earlier quoted context omitted.
"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…
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.)
- Boot into Recovery (hold cmd+R during boot)
- Open Disk Utility
- Unlock your system drive (assuming it's encrypted) -- I forget where exactly the option was but it's in DU somewhere.
- Open Terminal
- Go to your system drive now mounted under /Volumes and do what you gotta do.
Earlier 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.
> Homebrew wants it to be 775 root:admin It's worse than that. Homebrew wants 775 $(whoami):admin.
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…
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 just worked smoothly because every other Rails dev was walking the same path.
Homebrew exploded among ruby devs because adding new recipes to it was a couple of orders of magnitude easier (just write a few lines in a simple ruby DSL and send a pull request on Github) than MacPorts (hack about in bash cruft and then, what, open a ticket somewhere with a patch to ask for someone with an SVN commit bit to commit it, I guess?
Earlier quoted context omitted.
To add a directory to a system-protected directory. It's all about protecting the integrity of the installed system. If you don't like/want it, you can reboot into recovery, disable it, and leave it that way.
The integrity of the installed system could be violated by creating a directory ? My system was plenty protected already - it had a root account with a password only I knew. This is just more annoying Apple gatekeeping.
And yes, it is Apple "Gatekeeping"... the same gatekeeping that's kept OS X almost completely free of major hacks for over a decade. I don't consider that annoying but to each his own.
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.
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…
I always have Ubuntu Server running in the background in a VM, so I get the desktop experience that I prefer (Windows) and a better Unix experience than OS X provides.
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…
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't work if you moved them (e.g., if you wanted to use the frameworks to distribute an SDL-based game to your friends). This appears to be a choice that the MacPorts devs made explicitly, since standard source builds of SDL don't do that, and the standard SDL binaries don't do that.
I understand there are trade offs here, but the ones the MacPorts devs chose were not the ones I would have wanted. Homebrew, for better or worse, makes it much easier to make local changes to recipes, if you disagree with what the devs choose. However, I find that most of the disagreements I had with the MacPorts folks just haven't shown up with Homebrew.