16 ms·

El Capitan and Homebrew

540 points by juanfatas 11y ago

drinchev 11y ago
Yeah I see Permission denied messages everywhere now. $ brew update error: unable to unlink old '.gitignore' (Permission denied) error: unable to create file .travis.yml (Permission denied) error: unable to unlink old '.yardopts' (Permission denied) error: unable to unlink old 'README.md' (Permission denied) Error: Failure while executing: git pull --quiet origin refs/heads/master:refs/remotes/origin/master Nice. I saw that I can't change also system icons ( like Automator, AppStore, Maps, Notes, etc. ). Quick check on some forums suggest that I should do that in recovery mode. I guess it will be a mess with almost any other app that needs a bit more permissions and needs the raw UNIX filesystem.
- pilif 11y ago
  The only problem is that after the update, the /usr/local belongs to root again. That's easily fixed with a chown though. Apps still have access to the raw UNIX filesystem. The only restriction is that they can't write to /usr, /usr/bin, /usr/sbin, /System and into pre-installed Apple apps. Normally, Apps shouldn't need write access to these directories.
- eddieroger 11y ago
  It's not so much anything that needs the raw UNIX filesystem, it's anything that touches files that Apple has deemed not needing to be changeable, which I think app icons safely falls under. Fortunately, you can turn the whole thing off if you want.
t413 11y ago
Will homebrew switch the default install location out of /usr/local for new installations then? I doubt most developers will want to dive into recovery mode just to install wget.
- pilif 11y ago
  you don't need to. You only need to if you have manually deleted /usr/local for some reason. /usr/local is exempt from system integrity protection. The only problem is that its owner gets reset to root on every OS update, whereas Homebrew wants its owner to be the Homebrew user. The advantage of /usr/local as the installation root is that /usr/local/bin is in the default PATH of the OS and that setting the PATH in a way that it takes effect no matter what starts an application is a bit... tricky in OSX as there are many ways to launch an application that doesn't go through a shell, so .profile and friends aren't enough.
  - Tehnix 11y ago
    Are you sure it gets reset to root? I've been on since the first public beta, quickly fixed the homebrew problem, and haven't had any permission issues since. Admittedly I can't say if normal updates will behave different from the beta ones.
    - pilif 11y ago
      I can't be sure obviously, but if it's done once by the installer, there's no reason to assume it won't ever do it again. So in the worst case, you'll have to re-chown every time you install an update. Or you don't chown and run brew as root.
  - rsy96 11y ago
    But I've found that many GUI applications do not take /usr/local/bin into account. It's like only terminal applications, which are rightly affected by terminal environments, care about it.
shurcooL 11y ago
I just did this (from [1]): sudo chown -R $(whoami):admin /usr/local And not `sudo chown $(whoami):admin /usr/local`. Are both really necessary? [1]: https://news.ycombinator.com/item?id=10307800 https://news.ycombinator.com/item?id=10307800
- pilif 11y ago
  The -R was a bit overkill - what's inside /usr/local should already have had the correct owner - the problem is the owner of /usr/local itself.
  - mjs 11y ago
    The upgrade changes the permissions of all files within /usr/local to root:wheel.
    - m_eiman 11y ago
      Didn't for me, only /usr/local itself.
- favadi 11y ago
  No, only command with `-R` is necessary.
- 0x0 11y ago
  I'd say the "-R" might actually be harmful; for example the mysql GPL distribution binaries from dev.mysql.com installs in /usr/local/mysql and you definitively don't want to mess with the database file permissions there. It might not be "best practice" to let non-homebrew stuff put things in /usr/local, but it happens.
fleitz 11y ago
I'm starting to regret upgrading...
- JoachimS 11y ago
  El Capitan inclues a HUGE number of security fixes that you do want to have. https://support.apple.com/en-us/HT205267 https://support.apple.com/en-us/HT205267
  - carlosrg 11y ago
    Those fixes applicable to Yosemite will be available as a separate Security Update. Apple usually supports the current OS and the OS X version behind (for example, this for Mavericks was released in August: https://support.apple.com/kb/DL1834?viewlocale=en_US&locale=en_US https://support.apple.com/kb/DL1834?viewlocale=en_US&locale=...). So security is probably not a reason to upgrade.
    - JoachimS 11y ago
      Are they back porting rootless?
      - carlosrg 11y ago
        No, and thank God for that. The only thing Rootless prevents is system modification like iOS jailbreak, i.e. prevents tinkering with the system with things like debugging running processes or modifying system files (for example, utilities that modify the UI theme don't work with Rootless). Most malware out there is not that sophisticated, does not try to modify the OS and can still happily live in any other location of the system, like any other program.
senthilnayagam 11y ago
I update 6 hours ago and tweeted about it brew doctor brew prune sudo chown -R `whoami` /usr/local brew missing https://twitter.com/senthilnayagam/status/649400417323880448 https://twitter.com/senthilnayagam/status/649400417323880448
vbezhenar 11y ago
So I guess, for new installations it's better to put homebrew into $HOME?
- laurent123456 11y ago
  I was just reading the Arstechnica article, which mentions this: > Instead of allowing developers to put files wherever they want, El Cap offers four canonical safe locations for applications, support files, and drivers: > /Library > ~/Library > /usr/local > /Applications > The local or system library directories are the preferred stand-in for /System, and /usr/local is the preferred stand-in for /usr, /bin , and /sbin. However, Apple strongly recommends that developers use /Applications for everything if possible, since that keeps all of an app’s files in a single location for ease of uninstallation.
skrause 11y ago
Why does brew need to install everything owned by my user in /usr/local? I would honestly prefer if everything installed by brew was owned by root:wheel and brew would gracefully abort if I forgot to run it with sudo. Is all that current mess just so that I don't need sudo for brew?
- pilif 11y ago
  Then install brew with sudo.
  - skrause 11y ago
    This is what you used to see when you tried to use sudo with brew: Error: Cowardly refusing to `sudo brew install` You can use brew with sudo, but only if the brew executable is owned by root. However, this is both not recommended and completely unsupported so do so at your own risk. I don't know if it's different now, but a quick Google search indicates that brew still behaves like this. I would like to use brew with sudo, but I don't want to use unsupported methods.
    - mseri 11y ago
      You can create an admin account and use that ad indirection for dealing With homebrew
    - gutnor 11y ago
      Yes it is still like this. When XCode needed some license approval after the recent upgrade to support iOS9, Brew warned me that license can only be approved ( programatically ) by root. I tried to sudo brew and received the warning you showed. That was 1 week ago.
    - provemewrong 11y ago
      >so do so at your own risk. sudo su at your own risk, hehe.
- fit2rule 11y ago
  What is /usr/local for, if its not for locally installed (by the user) sub-components? Just curious whats wrong with using /usr/local. This is what its for, after all ..
alex1 11y ago
I'm curious to know if there's a reason everyone installs Homebrew in /usr/local (other than it being the default installation path). I've always chosen to install it in ~/.homebrew and haven't had any problems. Everything I install with Homebrew seems to handle an alternative prefix without issue.
- Tehnix 11y ago
  Because it has never caused any trouble having it in /usr/local, and as another user said /usr/local/bin is part of the standard path. Other than this one-liner, which is done once, there really isn't any extra hassle with using the default. I'd be more interested in why you didn't want to install it there?
  - rbinv 11y ago
    Actually it sounds like you will need to run this/restore permissions after every future OS X update.
    - Tehnix 11y ago
      Hmm, having been on El Capitan since the first beta, this hasn't happened. Do you have anywhere it states that?
      - rbinv 11y ago
        https://github.com/Homebrew/homebrew/blob/master/share/doc/homebrew/El_Capitan_and_Homebrew.md#el-capitan--homebrew https://github.com/Homebrew/homebrew/blob/master/share/doc/h... "Apple documentation hints that /usr/local will be returned to root:wheel restricted permissions on every OS X update; Homebrew will be adding a brew doctor check to warn you when this happens in the near future."
        crazysim 11y ago
        Perhaps they should consider adding an option to install something into launchd that just does this.
rolux 11y ago
How to disable SIP altogether: http://arstechnica.com/apple/2015/09/os-x-10-11-el-capitan-the-ars-technica-review/9/ http://arstechnica.com/apple/2015/09/os-x-10-11-el-capitan-t...
- mahouse 11y ago
  That requires nvram manipulation... Would it work well on a Hackintosh?
  - Karunamon 11y ago
    IIRC, all of the "nvram" stuff on a hackintosh actually exists as a flat config file in /Extras read by whatever bootloader you're using.
- urda 11y ago
  Much like 'goto' statements in code, unless you really have a good reason to do you shouldn't disable SIP.
  - aorth 11y ago
    Every time you disable SIP ... a kitten dies? Related, stop disabling SELinux! http://stopdisablingselinux.com/ http://stopdisablingselinux.com/
eccstartup 11y ago
Homebrew sounds like a malware of EI Capitan. :)
jackgavigan 11y ago
Couldn't all this be avoided if Homebrew installed itself in a sub-directory of /usr/local (e.g. /usr/local/homebrew) instead of /usr/local itself? Edit: For the avoidance of any doubt/confusion, this is what a virgin /usr/local/ looks like after Homebrew has been installed: $ ls -la /usr/local total 96 drwxrwxr-x 13 root admin 442 31 Aug 21:52 . drwxr-xr-x@ 12 root wheel 408 31 Aug 21:52 .. drwxr-xr-x 14 jgavigan admin 476 31 Aug 21:52 .git -rw-r--r-- 1 jgavigan admin 448 31 Aug 21:52 .gitignore -rw-r--r-- 1 jgavigan admin 291 31 Aug 21:52 .yardopts -rw-r--r-- 1 jgavigan admin 3161 31 Aug 21:52 CODEOFCONDUCT.md -rw-r--r-- 1 jgavigan admin 1103 31 Aug 21:52 CONTRIBUTING.md -rw-r--r-- 1 jgavigan admin 1241 31 Aug 21:52 LICENSE.txt drwxr-xr-x 9 jgavigan admin 306 31 Aug 21:52 Library -rw-r--r-- 1 jgavigan admin 2319 31 Aug 21:52 README.md -rw-r--r-- 1 jgavigan admin 23801 31 Aug 21:52 SUPPORTERS.md drwxr-xr-x 3 jgavigan admin 102 31 Aug 21:52 bin drwxr-xr-x 4 jgavigan admin 136 31 Aug 21:52 share
- runholm 11y ago
  That would break the unix convention they are trying to follow, so then they might as well put it anywhere else as well.
  - jackgavigan 11y ago
    What unix convention are you referring to?
    - marcosscriven 11y ago
      https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
      - jackgavigan 11y ago
        Okay, so can you explain to me how putting .git/, README.md and Cellar/ in /usr/local/ doesn't break that convention but putting them in /usr/local/homebrew/ does?
mjs 11y ago
Is this also related to why you can't rename /usr/local to /usr/local.old? (To do a fresh install of homebrew into /usr/local.) $ sudo mv local local.old mv: rename local to local.old: Operation not permitted
- raverbashing 11y ago
  mv /usr/local /tmp/local.old might work (or just somewhere outside of /usr)
antouank 11y ago
Installed El Capitan yesterday. Process took almost half an hour. Afterwards, brew just gave me a warning to do "chown" to my usr/local. That's it. Everything works fine.
- cbhl 11y ago
  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.
  - pilif 11y ago
    Not true. Even on a fresh install, /usr/local exists and is exempt from SIP
    - rimantas 11y ago
      Yes. I did a fresh install and homebrew had zero problems.
  - benihana 11y ago
    I bought a new Air in mid September. I was a little annoyed that documentation seemed out of date, but it took all of five minutes to fix this. No song and dance needed, just a sudo mkdir.
    - nkassis 11y ago
      But his comment refers to the new OS changes I believe thus it's going to be a pain going forward.
      - slowhands 11y ago
        I just installed brew on a brand-new El Capitan install with 0 problems.
  - 11y ago
dvcrn 11y ago
The first thing I did after the upgrade was disabling SIP. Now my system acts exactly the same way before with all the goodies (except rootless) el capitan has to offer. Having root not able to write system stuff is good for people that like to blindly execute shell scripts from the internet but I think apple should add something that makes it easier for developers to disable it. I don't know if there is a new method yet, but before you had to boot into recovery and execute `csrutil disable`. In the early days there was a boot flag you could set but that got removed quickly.
- Zirro 11y ago
  It has to be a method that can not be accessed by malware - the very thing SIP is meant to protect from. I believe that is the reason the option ended up on the recovery partition.
nailer 11y ago
This is one of the reasons I love HN: a grapevine of important things to help developers fix their dev environments, security things we need to be aware of for our servers, new APIs to take advantage of, and other important stuff.
- q3k 11y ago
  Well, if you use OS X, write against Node.JS, work at a SV startup and are interested in big data / machine learning. It is quite a bubble.
  - kweinber 11y ago
    Isn't using the word "bubble" against official HN rules?
  - thibaut_barrere 11y ago
    I live in a rural part of France, use OS X, Ruby/Elixir, I'm not working for any SV startup, and indeed what the OP describes in one of my favorite things in HN!
  - Killswitch 11y ago
    I use OS X, write Node.js, live in Northeast Iowa and I too find the information great, like OP said.
TurboHaskal 11y ago
There hasn't been a clean upgrade in ages, yet developers eat that shit up and keep showing up with their shiny MacBooks in conferences. It must be great being a second class citizen.
- colinplamondon 11y ago
  Worst case is a half-day of cleanup once in a year to keep your computer secure and up to date. Most years (like this one!) there's a one-liner for Homebrew upvoted to the top of HN, and that's it.
- JustSomeNobody 11y ago
  Why do you feel this way? I mean, seriously, at the end of the day we're talking about computers and operating systems. That's it. No reason to be upset. It's just stuff.
LaSombra 11y ago
To me, the fact that you are directed to install Homebrew to /usr/local is wrong since there's no guarantee how /usr/local is going to treated by Apple in the future and this is now an example of that. The only directory that Apple, probably, doesn't have control is your home directory. I've been using homebrew for a long time without issues because, in my opinion, I installed it on ~/homebrew. I wonder why is that so difficult for others to use.
- rsy96 11y ago
  Because the default is in `/usr/local` and because the installation warns against changing prefix for possible software breakage. Now since many people say they never run into problems with nonstandard homebrew path, I'd like to give it a try too.
- gnurag 11y ago
  Apple has indicated that even with SIP, they're leaving /usr/local available for developers. ref: Apple keynote slide #35 on http://devstreaming.apple.com/videos/wwdc/2015/706nu20qkag/706/706_security_and_your_apps.pdf?dl=1 http://devstreaming.apple.com/videos/wwdc/2015/706nu20qkag/7...
quotemstr 11y ago
Users should have full control over their own machines. System Integrity Protection is obnoxious paternalism at best, and at worst, it's just another step toward iOS-ification. If Apple keeps this up, I expect a revival of Linux desktop distributions.
- rimantas 11y ago
  Yeah, iPhone a very very unpopular for this reason, right? You have the same amount of control, this is an option you can disable if you need to. I think the amount of people who need that is very small, even among technical crowd.
- cmdkeen 11y ago
  They do have full control - see the bit about being able to disable/enable via recovery mode. I for one am very happy to have moved on from an era where desktop security was abysmal and compromises lurked around every corner.
- stock_toaster 11y ago
  Isn't the goal to prevent malware from modifying core system files? How different is this than a simple mandatory access implementation? As long as it is possible to disable it, should I choose to, I am not outraged.
- jawngee 11y ago
  Yes, 2016 might very well be the year of the Linux desktop.
- hamstergene 11y ago
  The common problem of today OSes is that shall malware breach security at least once, it can hide in the system and you will have no idea that you have it. SIP is a good step towards fixing that problem.
- Osmium 11y ago
  > Users should have full control over their own machines. Agreed. > System Integrity Protection is obnoxious paternalism at best Couldn't disagree more. The user maintains full control: you can disable it at will, temporarily or permanently. Protections like this are becoming essential as a result of current malware threats. Thanks to System Integrity Protection, we're now much more protected against rootkits and similar attacks. This is a good thing. I feel like I have to keep defending it because it's perceived as this removal of user freedoms, when it's factually just not the case–you can still do everything you could do before, you just have to restart into recovery mode to do so (to be able to do this without the restart into recovery mode would undermine the security this technology provides). System Integrity Protection is closer in spirit to something like SELinux than anything.
sabujp 11y ago
osx just got selinux?
atmosx 11y ago
My MacTex (Latex) installation broke for the same reason. Luckily, all I had to do was set put "/Library/TeX/Root/bin/universal-darwin/" in my $PATH and change the path of "pdtlatex" and "bibtex" to the GUI tools I use. But still, I lost about an hour or so trying to figure out what is happening.
glogla 11y ago
Homebrew troubles aside, does System Integrity Protection means the end of OpenVPN and FUSE on Mac OS? Those need to add kernel modules and such.
- joosters 11y ago
  Yosemite already prevented unsigned kernel modules, so I don't think anything will change here.
- Zirro 11y ago
  No, I have used OpenVPN throughout the betas without issues, and OSXFUSE added support in version 2.8.
- rsy96 11y ago
  No. The official installers are signed, and are thus not prevented.
littlewing 11y ago
When I first read this I was a little pissed at Apple, but what if brew were to install everything to /brew? It doesn't need to install into /usr/local.
- deong 11y ago
  You'd run into exactly the same problem. Apple doesn't provide /brew in the default image, so something would have to create a new inode in /, and that something presumably requires SIP be disabled (assuming / is protected in SIP at least). Even if it worked, you'd be no better off than just using ~/.homebrew or something like it. Their whole reason for wanting /usr/local is that (a) /usr/local/bin is in the default $PATH, and (b) it can be written to by a normal user. Using /brew gives up (a) anyway, so you may as well just put it in a user's home directory somewhere.
  - quesera 11y ago
    > You'd run into exactly the same problem. I think you misunderstand the problem. /usr/local exists in OSX, and is one of the recommended install locations for user software. But if you change the permissions on /usr/local, OSX will interpret that as damage and fix it. Homebrew does this, which is in conflict with all uses of /usr/local in Unix history. > and (b) it can be written to by a normal user. Critically, no. This is a security risk. A larger one back when multiuser systems were the only Unix systems, but still a risk. Violates all standards, even the ones OSX doesn't attempt to comply with.
    - deong 11y ago
      Oh, I know it's a huge problem on multi-user systems. I was just pointing out that homebrew treats it that way so they can have sudo-less access. Technically I guess it's not world writable in a default homebrew install though, just owned by a normal user. Which also defeats the purpose of /usr/local really, but I've never found that design decision from Homebrew to be very good. It is entirely possible I misunderstood SIP. The first thing I did was disable it, and I haven't bothered any more about it. My impression though was that it locked down all "system directories", however Apple chooses to define that. Which would disallow changing the permissions on /usr/local, but also would disallow creating new files or directories under a protected directory. Is that not what it does?
aorth 11y ago
If you only need a Unix-style package manager for things like coreutils, nodejs, tmux, irssi, vim, etc, pkgsrc runs on OS X and installs to /opt/pkg. There is no Google Chrome, or fonts, etc in it though, so if you enjoy installing those from Homebrew then this is not for you. http://pkgsrc.joyent.com/install-on-osx/ http://pkgsrc.joyent.com/install-on-osx/
iuguy 11y ago
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.
- jrochkind1 11y ago
  What makes you think /usr/local isn't a 'common unix standard'?
  - pjmlp 11y ago
    Never used Homebrew, but taking ownership of /user/local as I understand it does by default, certainly isn't a 'common unix standard'.
    - baldfat 11y ago
      > 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 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?
      - dyladan 11y ago
        I don't see anywhere in there where it says you should take ownership of /usr/local
        baldfat 11y ago
        That is why I said I searched and got the standard for the person who said "certainly it isn't the standard." We have the ultimate resource to know the answer to any question that does have an answer. I gave this down voted "I googled it for you" because people need to just look up what the Standard is and than speak from a position of knowledge and not some vague non-answer. For the still lazy the Unix File Hierarchy Standard for /usr /usr is the second major section of the filesystem. /usr is shareable, read-only data. That means that /usr should be shareable between various FHS-compliant hosts and must not be written to. Any information that is host-specific or varies with time is stored elsewhere. Large software packages must not use a direct subdirectory under the /usr hierarchy.
ohthehugemanate 11y ago
In case it's helpful, I blogged the steps I had to take to get my environment back up and running: https://ohthehugemanatee.org/blog/2015/10/01/how-i-got-el-capitain-working-with-my-developer-tools/ https://ohthehugemanatee.org/blog/2015/10/01/how-i-got-el-ca...
omegote 11y ago
Shit like this happens everyday and yet many regard OS X as the best development platform. Wtf?
- thom_nic 11y ago
  If by "every day" you mean "when there's a major version release," then yes. Major releases bring potentially breaking changes.
- eggie 11y ago
  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 life. Exploding batteries. Horrible one-way OS upgrades. I thought it'd be helpful for art and music software, but I found the opposite. I thought it'd be good for programming but had to invest absurd amounts of time in installing basic open source development software. Never again.
  - omegote 11y ago
    +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.
  - oldmanjay 11y ago
    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.
- umanwizard 11y ago
  Nobody else sells nice, super-useable, high-end UNIX personal workstations. Agree with your point -- Apple is a developer-hostile company and their OS is bad for people whose work involves tinkering with computers. Still the best development platform, though, which is a sorry state of affairs.
phkahler 11y ago
Should I create this folder or install brew now? I've been thinking about installing it on my macbook and doing some development on it but haven't yet. Last night it told me the OSX update was available. Which order should I do this? Or should I just not put brew in /usr/local ??
- occam65 11y ago
  I definitely recommend installing El Capitan first, followed by Homebrew. That will lead to less possibility of the upgrade screwing with your Homebrew installation.
anuraaga 11y ago
Before Apple there was companies' IT's Puppet mangaging away /usr/local from usefulness. Main reason I only use Macports which has never failed me.
sandaru1 11y ago
Just make sure that if there are any launch daemons plist files, those should be root:wheel. Otherwise "launchctl" won't load those daemons.
liveoneggs 11y ago
pkgsrc allows you to build into any directory you want.
rhapsodyv 11y ago
Anyone having issues with macports too?
lectrick 11y ago
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 directory lives, anyway.
- tvon 11y ago
  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.
  - spinlock 11y ago
    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).
    - tvon 11y ago
      It's in /opt, so it's just: PATH=/opt/homebrew/bin:/opt/homebrew/sbin:$PATH I considered a ~/ directory but wanted it available for the rare occasion when there is someone ssh'd into my machine (though I didn't go so far as to update the system-wide shell configs to use it.
- berdario 11y ago
  It's very common for linux applications to store stuff in $XDG_DATA_HOME (~/.local/share by default) (config files and caches go somewhere else) In my ~/.local I also have a bin/ directory (created by some Haskell tool), so rather than putting stuff in /Users/username/usr/local, I think it might make more sense to recreate the (needed parts of) a unix fs hierarchy in /Users/username/.local There's also ~/LibrarySupport on Macosx, if I remember correctly... but I think that contains user editable configuration files as well
amelius 11y ago
Concepts such as "ownership" and "permissions" have always been a bit of an issue with Apple.
dafstone 11y ago
I installed El Capitan this morning and was expecting to have to do this - I did not. chown stayed owned to me properly, brew functioned as it was before... everything fine.
- evolve2k 11y ago
  Did you do anything in advance of the install? Eg some people were mentioning earlier to move files out of bin/local before upgrade then copy them back in. Do anything like that?
- evolve2k 11y ago
  Did you do anything in advance of the install? Eg some people were mentioning earlier to move files out of usr/local before upgrade then copy them back in. Do anything like that?
mapgrep 11y ago
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 libraries for various things. But then it is much more fragile when your system updates. Macports really only depends on a slice of Xcode; from time to time updates will fail to install until you open Xcode and accept whatever new license Apple has bundled with it. But you don't get key components changing out from underneath your packages due to an Apple System Update. My bias here is that I'm a longtime happy Macports user who has tried to use homebrew repeatedly, encountered lots of failed recipes, and gone back to Macports, shaking my head at all the hype around homebrew and the fact that is has somehow become a defacto developer default despite some really sloppy, poorly thought through practices. (And I know that's harsh but for a long time they trashed Macports right in their tagline — "Is MacPorts driving you to drink?" — which just seemed gratuitous.)
- outworlder 11y ago
  Perhaps the easy of writing recipes, combined with good timing (Ruby was all the rage), is what made people go to homebrew.
- joshmoz 11y ago
  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 projects and I can't tell you how many times they've made a mess with homebrew, nothing works. Replace homebrew with macports and their problems are solved, rarely to return. Maybe in some cases homebrew installs something a bit faster, but it's rarely a meaningful amount of time and it doesn't make up for all the time spent fixing homebrew when it messes up.
  - 11y ago
heimatau 11y ago
This 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 from me. I'm not sure what to do to fix this.
- mzs 11y ago
  Maybe clear your kext cache. Also boot it single user mode so you can see where it fails.
grandalf 11y ago
Dear Apple: Please start using apt
schmichael 11y ago
Why does homebrew install things as root anyway? Seems like defaulting to installing in your home directory would be a much better practice.
- superchink 11y ago
  Homebrew does not advocate installing things as root. You can read more about it here: https://github.com/Homebrew/homebrew/blob/master/share/doc/homebrew/FAQ.md#why-does-homebrew-say-sudo-is-bad- https://github.com/Homebrew/homebrew/blob/master/share/doc/h...
  - schmichael 11y ago
    Fantastic! Then why is this an issue?
    - s73v3r 11y ago
      They want /usr/local to be owned by you.
      - schmichael 11y ago
        That kind of blows my mind... why not use homedirs instead of abusing global paths!?
        s73v3r 11y ago
        If it's in a home directory, then the stuff installed is really only usable by that person. I can see some instances where that would be desirable, but I would prefer that the stuff I install is usable by the whole system, even though I'm the only one on the machine.
racl101 11y ago
Ugh, why does Apple try to subdue its customers. If I want root access to a directory that's my problem. They don't need to police what I do.
neckro23 11y ago
By the way, there's a way to create /usr/local without rebooting four times like suggested in the doc: - 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.
mozumder 11y ago
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.
No1 11y ago
Does is still take a few hours to copy over /usr/local during the upgrade like it did during the Yosemite upgrade or has Apple fixed that? I'm glad I read this before moving the /usr/local directory as was previously suggested https://jimlindley.com/blog/yosemite-upgrade-homebrew-tips/ https://jimlindley.com/blog/yosemite-upgrade-homebrew-tips/
ilaksh 11y ago
Using a $150 Chromebook from Walmart with the built-in ssh and my VPSs or xfce via crouton when I feel like it. Works great for web development. No UNIX/linux compatibility problems since it is actually Linux.
l3x5 11y ago
It's easy to get Homebrew and Java running smoothly after the El Capitan upgrade. Read this: http://lexsheehan.blogspot.com/2015/10/el-capitan-homebrew-and-java.html http://lexsheehan.blogspot.com/2015/10/el-capitan-homebrew-a...

540 points by juanfatas 11y ago

Yeah I see Permission denied messages everywhere now. $ brew update error: unable to unlink old '.gitignore' (Permission denied) error: unable to create file .travis.yml (Permission denied) error: unable to unlink old '.yardopts' (Permission denied) error: unable to unlink old 'README.md' (Permission denied) Error: Failure while executing: git pull --quiet origin refs/heads/master:refs/remotes/origin/master Nice. I saw that I can't change also system icons ( like Automator, AppStore, Maps, Notes, etc. ). Quick check on some forums suggest that I should do that in recovery mode. I guess it will be a mess with almost any other app that needs a bit more permissions and needs the raw UNIX filesystem.

pilif 11y ago
The only problem is that after the update, the /usr/local belongs to root again. That's easily fixed with a chown though. Apps still have access to the raw UNIX filesystem. The only restriction is that they can't write to /usr, /usr/bin, /usr/sbin, /System and into pre-installed Apple apps. Normally, Apps shouldn't need write access to these directories.
eddieroger 11y ago
It's not so much anything that needs the raw UNIX filesystem, it's anything that touches files that Apple has deemed not needing to be changeable, which I think app icons safely falls under. Fortunately, you can turn the whole thing off if you want.

t413 11y ago

Will homebrew switch the default install location out of /usr/local for new installations then? I doubt most developers will want to dive into recovery mode just to install wget.

pilif 11y ago
you don't need to. You only need to if you have manually deleted /usr/local for some reason. /usr/local is exempt from system integrity protection. The only problem is that its owner gets reset to root on every OS update, whereas Homebrew wants its owner to be the Homebrew user. The advantage of /usr/local as the installation root is that /usr/local/bin is in the default PATH of the OS and that setting the PATH in a way that it takes effect no matter what starts an application is a bit... tricky in OSX as there are many ways to launch an application that doesn't go through a shell, so .profile and friends aren't enough.
- Tehnix 11y ago
  Are you sure it gets reset to root? I've been on since the first public beta, quickly fixed the homebrew problem, and haven't had any permission issues since. Admittedly I can't say if normal updates will behave different from the beta ones.
  - pilif 11y ago
    I can't be sure obviously, but if it's done once by the installer, there's no reason to assume it won't ever do it again. So in the worst case, you'll have to re-chown every time you install an update. Or you don't chown and run brew as root.
- rsy96 11y ago
  But I've found that many GUI applications do not take /usr/local/bin into account. It's like only terminal applications, which are rightly affected by terminal environments, care about it.

shurcooL 11y ago

I just did this (from [1]): sudo chown -R $(whoami):admin /usr/local And not `sudo chown $(whoami):admin /usr/local`. Are both really necessary? [1]: https://news.ycombinator.com/item?id=10307800 https://news.ycombinator.com/item?id=10307800

pilif 11y ago
The -R was a bit overkill - what's inside /usr/local should already have had the correct owner - the problem is the owner of /usr/local itself.
- mjs 11y ago
  The upgrade changes the permissions of all files within /usr/local to root:wheel.
  - m_eiman 11y ago
    Didn't for me, only /usr/local itself.
favadi 11y ago
No, only command with `-R` is necessary.
0x0 11y ago
I'd say the "-R" might actually be harmful; for example the mysql GPL distribution binaries from dev.mysql.com installs in /usr/local/mysql and you definitively don't want to mess with the database file permissions there. It might not be "best practice" to let non-homebrew stuff put things in /usr/local, but it happens.

fleitz 11y ago

I'm starting to regret upgrading...

JoachimS 11y ago
El Capitan inclues a HUGE number of security fixes that you do want to have. https://support.apple.com/en-us/HT205267 https://support.apple.com/en-us/HT205267
- carlosrg 11y ago
  Those fixes applicable to Yosemite will be available as a separate Security Update. Apple usually supports the current OS and the OS X version behind (for example, this for Mavericks was released in August: https://support.apple.com/kb/DL1834?viewlocale=en_US&locale=en_US https://support.apple.com/kb/DL1834?viewlocale=en_US&locale=...). So security is probably not a reason to upgrade.
  - JoachimS 11y ago
    Are they back porting rootless?
    - carlosrg 11y ago
      No, and thank God for that. The only thing Rootless prevents is system modification like iOS jailbreak, i.e. prevents tinkering with the system with things like debugging running processes or modifying system files (for example, utilities that modify the UI theme don't work with Rootless). Most malware out there is not that sophisticated, does not try to modify the OS and can still happily live in any other location of the system, like any other program.

senthilnayagam 11y ago

I update 6 hours ago and tweeted about it brew doctor brew prune sudo chown -R `whoami` /usr/local brew missing https://twitter.com/senthilnayagam/status/649400417323880448 https://twitter.com/senthilnayagam/status/649400417323880448

vbezhenar 11y ago

So I guess, for new installations it's better to put homebrew into $HOME?

laurent123456 11y ago
I was just reading the Arstechnica article, which mentions this: > Instead of allowing developers to put files wherever they want, El Cap offers four canonical safe locations for applications, support files, and drivers: > /Library > ~/Library > /usr/local > /Applications > The local or system library directories are the preferred stand-in for /System, and /usr/local is the preferred stand-in for /usr, /bin , and /sbin. However, Apple strongly recommends that developers use /Applications for everything if possible, since that keeps all of an app’s files in a single location for ease of uninstallation.

skrause 11y ago

Why does brew need to install everything owned by my user in /usr/local? I would honestly prefer if everything installed by brew was owned by root:wheel and brew would gracefully abort if I forgot to run it with sudo. Is all that current mess just so that I don't need sudo for brew?

pilif 11y ago
Then install brew with sudo.
- skrause 11y ago
  This is what you used to see when you tried to use sudo with brew: Error: Cowardly refusing to `sudo brew install` You can use brew with sudo, but only if the brew executable is owned by root. However, this is both not recommended and completely unsupported so do so at your own risk. I don't know if it's different now, but a quick Google search indicates that brew still behaves like this. I would like to use brew with sudo, but I don't want to use unsupported methods.
  - mseri 11y ago
    You can create an admin account and use that ad indirection for dealing With homebrew
  - gutnor 11y ago
    Yes it is still like this. When XCode needed some license approval after the recent upgrade to support iOS9, Brew warned me that license can only be approved ( programatically ) by root. I tried to sudo brew and received the warning you showed. That was 1 week ago.
  - provemewrong 11y ago
    >so do so at your own risk. sudo su at your own risk, hehe.
fit2rule 11y ago
What is /usr/local for, if its not for locally installed (by the user) sub-components? Just curious whats wrong with using /usr/local. This is what its for, after all ..

alex1 11y ago

I'm curious to know if there's a reason everyone installs Homebrew in /usr/local (other than it being the default installation path). I've always chosen to install it in ~/.homebrew and haven't had any problems. Everything I install with Homebrew seems to handle an alternative prefix without issue.

Tehnix 11y ago
Because it has never caused any trouble having it in /usr/local, and as another user said /usr/local/bin is part of the standard path. Other than this one-liner, which is done once, there really isn't any extra hassle with using the default. I'd be more interested in why you didn't want to install it there?
- rbinv 11y ago
  Actually it sounds like you will need to run this/restore permissions after every future OS X update.
  - Tehnix 11y ago
    Hmm, having been on El Capitan since the first beta, this hasn't happened. Do you have anywhere it states that?
    - rbinv 11y ago
      https://github.com/Homebrew/homebrew/blob/master/share/doc/homebrew/El_Capitan_and_Homebrew.md#el-capitan--homebrew https://github.com/Homebrew/homebrew/blob/master/share/doc/h... "Apple documentation hints that /usr/local will be returned to root:wheel restricted permissions on every OS X update; Homebrew will be adding a brew doctor check to warn you when this happens in the near future."
      - crazysim 11y ago
        Perhaps they should consider adding an option to install something into launchd that just does this.

rolux 11y ago

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

mahouse 11y ago
That requires nvram manipulation... Would it work well on a Hackintosh?
- Karunamon 11y ago
  IIRC, all of the "nvram" stuff on a hackintosh actually exists as a flat config file in /Extras read by whatever bootloader you're using.
urda 11y ago
Much like 'goto' statements in code, unless you really have a good reason to do you shouldn't disable SIP.
- aorth 11y ago
  Every time you disable SIP ... a kitten dies? Related, stop disabling SELinux! http://stopdisablingselinux.com/ http://stopdisablingselinux.com/

eccstartup 11y ago

Homebrew sounds like a malware of EI Capitan. :)

jackgavigan 11y ago

Couldn't all this be avoided if Homebrew installed itself in a sub-directory of /usr/local (e.g. /usr/local/homebrew) instead of /usr/local itself? Edit: For the avoidance of any doubt/confusion, this is what a virgin /usr/local/ looks like after Homebrew has been installed: $ ls -la /usr/local total 96 drwxrwxr-x 13 root admin 442 31 Aug 21:52 . drwxr-xr-x@ 12 root wheel 408 31 Aug 21:52 .. drwxr-xr-x 14 jgavigan admin 476 31 Aug 21:52 .git -rw-r--r-- 1 jgavigan admin 448 31 Aug 21:52 .gitignore -rw-r--r-- 1 jgavigan admin 291 31 Aug 21:52 .yardopts -rw-r--r-- 1 jgavigan admin 3161 31 Aug 21:52 CODEOFCONDUCT.md -rw-r--r-- 1 jgavigan admin 1103 31 Aug 21:52 CONTRIBUTING.md -rw-r--r-- 1 jgavigan admin 1241 31 Aug 21:52 LICENSE.txt drwxr-xr-x 9 jgavigan admin 306 31 Aug 21:52 Library -rw-r--r-- 1 jgavigan admin 2319 31 Aug 21:52 README.md -rw-r--r-- 1 jgavigan admin 23801 31 Aug 21:52 SUPPORTERS.md drwxr-xr-x 3 jgavigan admin 102 31 Aug 21:52 bin drwxr-xr-x 4 jgavigan admin 136 31 Aug 21:52 share

runholm 11y ago
That would break the unix convention they are trying to follow, so then they might as well put it anywhere else as well.
- jackgavigan 11y ago
  What unix convention are you referring to?
  - marcosscriven 11y ago
    https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
    - jackgavigan 11y ago
      Okay, so can you explain to me how putting .git/, README.md and Cellar/ in /usr/local/ doesn't break that convention but putting them in /usr/local/homebrew/ does?

mjs 11y ago

Is this also related to why you can't rename /usr/local to /usr/local.old? (To do a fresh install of homebrew into /usr/local.) $ sudo mv local local.old mv: rename local to local.old: Operation not permitted

raverbashing 11y ago
mv /usr/local /tmp/local.old might work (or just somewhere outside of /usr)

antouank 11y ago

Installed El Capitan yesterday. Process took almost half an hour. Afterwards, brew just gave me a warning to do "chown" to my usr/local. That's it. Everything works fine.

cbhl 11y ago
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.
- pilif 11y ago
  Not true. Even on a fresh install, /usr/local exists and is exempt from SIP
  - rimantas 11y ago
    Yes. I did a fresh install and homebrew had zero problems.
- benihana 11y ago
  I bought a new Air in mid September. I was a little annoyed that documentation seemed out of date, but it took all of five minutes to fix this. No song and dance needed, just a sudo mkdir.
  - nkassis 11y ago
    But his comment refers to the new OS changes I believe thus it's going to be a pain going forward.
    - slowhands 11y ago
      I just installed brew on a brand-new El Capitan install with 0 problems.
- 11y ago

dvcrn 11y ago

The first thing I did after the upgrade was disabling SIP. Now my system acts exactly the same way before with all the goodies (except rootless) el capitan has to offer. Having root not able to write system stuff is good for people that like to blindly execute shell scripts from the internet but I think apple should add something that makes it easier for developers to disable it. I don't know if there is a new method yet, but before you had to boot into recovery and execute `csrutil disable`. In the early days there was a boot flag you could set but that got removed quickly.

Zirro 11y ago
It has to be a method that can not be accessed by malware - the very thing SIP is meant to protect from. I believe that is the reason the option ended up on the recovery partition.

nailer 11y ago

This is one of the reasons I love HN: a grapevine of important things to help developers fix their dev environments, security things we need to be aware of for our servers, new APIs to take advantage of, and other important stuff.

q3k 11y ago
Well, if you use OS X, write against Node.JS, work at a SV startup and are interested in big data / machine learning. It is quite a bubble.
- kweinber 11y ago
  Isn't using the word "bubble" against official HN rules?
- thibaut_barrere 11y ago
  I live in a rural part of France, use OS X, Ruby/Elixir, I'm not working for any SV startup, and indeed what the OP describes in one of my favorite things in HN!
- Killswitch 11y ago
  I use OS X, write Node.js, live in Northeast Iowa and I too find the information great, like OP said.

TurboHaskal 11y ago

There hasn't been a clean upgrade in ages, yet developers eat that shit up and keep showing up with their shiny MacBooks in conferences. It must be great being a second class citizen.

colinplamondon 11y ago
Worst case is a half-day of cleanup once in a year to keep your computer secure and up to date. Most years (like this one!) there's a one-liner for Homebrew upvoted to the top of HN, and that's it.
JustSomeNobody 11y ago
Why do you feel this way? I mean, seriously, at the end of the day we're talking about computers and operating systems. That's it. No reason to be upset. It's just stuff.

LaSombra 11y ago

To me, the fact that you are directed to install Homebrew to /usr/local is wrong since there's no guarantee how /usr/local is going to treated by Apple in the future and this is now an example of that. The only directory that Apple, probably, doesn't have control is your home directory. I've been using homebrew for a long time without issues because, in my opinion, I installed it on ~/homebrew. I wonder why is that so difficult for others to use.

rsy96 11y ago
Because the default is in `/usr/local` and because the installation warns against changing prefix for possible software breakage. Now since many people say they never run into problems with nonstandard homebrew path, I'd like to give it a try too.
gnurag 11y ago
Apple has indicated that even with SIP, they're leaving /usr/local available for developers. ref: Apple keynote slide #35 on http://devstreaming.apple.com/videos/wwdc/2015/706nu20qkag/706/706_security_and_your_apps.pdf?dl=1 http://devstreaming.apple.com/videos/wwdc/2015/706nu20qkag/7...

quotemstr 11y ago

Users should have full control over their own machines. System Integrity Protection is obnoxious paternalism at best, and at worst, it's just another step toward iOS-ification. If Apple keeps this up, I expect a revival of Linux desktop distributions.

rimantas 11y ago
Yeah, iPhone a very very unpopular for this reason, right? You have the same amount of control, this is an option you can disable if you need to. I think the amount of people who need that is very small, even among technical crowd.
cmdkeen 11y ago
They do have full control - see the bit about being able to disable/enable via recovery mode. I for one am very happy to have moved on from an era where desktop security was abysmal and compromises lurked around every corner.
stock_toaster 11y ago
Isn't the goal to prevent malware from modifying core system files? How different is this than a simple mandatory access implementation? As long as it is possible to disable it, should I choose to, I am not outraged.
jawngee 11y ago
Yes, 2016 might very well be the year of the Linux desktop.
hamstergene 11y ago
The common problem of today OSes is that shall malware breach security at least once, it can hide in the system and you will have no idea that you have it. SIP is a good step towards fixing that problem.
Osmium 11y ago
> Users should have full control over their own machines. Agreed. > System Integrity Protection is obnoxious paternalism at best Couldn't disagree more. The user maintains full control: you can disable it at will, temporarily or permanently. Protections like this are becoming essential as a result of current malware threats. Thanks to System Integrity Protection, we're now much more protected against rootkits and similar attacks. This is a good thing. I feel like I have to keep defending it because it's perceived as this removal of user freedoms, when it's factually just not the case–you can still do everything you could do before, you just have to restart into recovery mode to do so (to be able to do this without the restart into recovery mode would undermine the security this technology provides). System Integrity Protection is closer in spirit to something like SELinux than anything.

sabujp 11y ago

osx just got selinux?

atmosx 11y ago

My MacTex (Latex) installation broke for the same reason. Luckily, all I had to do was set put "/Library/TeX/Root/bin/universal-darwin/" in my $PATH and change the path of "pdtlatex" and "bibtex" to the GUI tools I use. But still, I lost about an hour or so trying to figure out what is happening.

glogla 11y ago

Homebrew troubles aside, does System Integrity Protection means the end of OpenVPN and FUSE on Mac OS? Those need to add kernel modules and such.

joosters 11y ago
Yosemite already prevented unsigned kernel modules, so I don't think anything will change here.
Zirro 11y ago
No, I have used OpenVPN throughout the betas without issues, and OSXFUSE added support in version 2.8.
rsy96 11y ago
No. The official installers are signed, and are thus not prevented.

littlewing 11y ago

When I first read this I was a little pissed at Apple, but what if brew were to install everything to /brew? It doesn't need to install into /usr/local.

deong 11y ago
You'd run into exactly the same problem. Apple doesn't provide /brew in the default image, so something would have to create a new inode in /, and that something presumably requires SIP be disabled (assuming / is protected in SIP at least). Even if it worked, you'd be no better off than just using ~/.homebrew or something like it. Their whole reason for wanting /usr/local is that (a) /usr/local/bin is in the default $PATH, and (b) it can be written to by a normal user. Using /brew gives up (a) anyway, so you may as well just put it in a user's home directory somewhere.
- quesera 11y ago
  > You'd run into exactly the same problem. I think you misunderstand the problem. /usr/local exists in OSX, and is one of the recommended install locations for user software. But if you change the permissions on /usr/local, OSX will interpret that as damage and fix it. Homebrew does this, which is in conflict with all uses of /usr/local in Unix history. > and (b) it can be written to by a normal user. Critically, no. This is a security risk. A larger one back when multiuser systems were the only Unix systems, but still a risk. Violates all standards, even the ones OSX doesn't attempt to comply with.
  - deong 11y ago
    Oh, I know it's a huge problem on multi-user systems. I was just pointing out that homebrew treats it that way so they can have sudo-less access. Technically I guess it's not world writable in a default homebrew install though, just owned by a normal user. Which also defeats the purpose of /usr/local really, but I've never found that design decision from Homebrew to be very good. It is entirely possible I misunderstood SIP. The first thing I did was disable it, and I haven't bothered any more about it. My impression though was that it locked down all "system directories", however Apple chooses to define that. Which would disallow changing the permissions on /usr/local, but also would disallow creating new files or directories under a protected directory. Is that not what it does?

aorth 11y ago

If you only need a Unix-style package manager for things like coreutils, nodejs, tmux, irssi, vim, etc, pkgsrc runs on OS X and installs to /opt/pkg. There is no Google Chrome, or fonts, etc in it though, so if you enjoy installing those from Homebrew then this is not for you. http://pkgsrc.joyent.com/install-on-osx/ http://pkgsrc.joyent.com/install-on-osx/

iuguy 11y ago

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.

jrochkind1 11y ago
What makes you think /usr/local isn't a 'common unix standard'?
- pjmlp 11y ago
  Never used Homebrew, but taking ownership of /user/local as I understand it does by default, certainly isn't a 'common unix standard'.
  - baldfat 11y ago
    > 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 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?
    - dyladan 11y ago
      I don't see anywhere in there where it says you should take ownership of /usr/local
      - baldfat 11y ago
        That is why I said I searched and got the standard for the person who said "certainly it isn't the standard." We have the ultimate resource to know the answer to any question that does have an answer. I gave this down voted "I googled it for you" because people need to just look up what the Standard is and than speak from a position of knowledge and not some vague non-answer. For the still lazy the Unix File Hierarchy Standard for /usr /usr is the second major section of the filesystem. /usr is shareable, read-only data. That means that /usr should be shareable between various FHS-compliant hosts and must not be written to. Any information that is host-specific or varies with time is stored elsewhere. Large software packages must not use a direct subdirectory under the /usr hierarchy.

ohthehugemanate 11y ago

In case it's helpful, I blogged the steps I had to take to get my environment back up and running: https://ohthehugemanatee.org/blog/2015/10/01/how-i-got-el-capitain-working-with-my-developer-tools/ https://ohthehugemanatee.org/blog/2015/10/01/how-i-got-el-ca...

omegote 11y ago

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

thom_nic 11y ago
If by "every day" you mean "when there's a major version release," then yes. Major releases bring potentially breaking changes.
eggie 11y ago
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 life. Exploding batteries. Horrible one-way OS upgrades. I thought it'd be helpful for art and music software, but I found the opposite. I thought it'd be good for programming but had to invest absurd amounts of time in installing basic open source development software. Never again.
- omegote 11y ago
  +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.
- oldmanjay 11y ago
  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.
umanwizard 11y ago
Nobody else sells nice, super-useable, high-end UNIX personal workstations. Agree with your point -- Apple is a developer-hostile company and their OS is bad for people whose work involves tinkering with computers. Still the best development platform, though, which is a sorry state of affairs.

phkahler 11y ago

Should I create this folder or install brew now? I've been thinking about installing it on my macbook and doing some development on it but haven't yet. Last night it told me the OSX update was available. Which order should I do this? Or should I just not put brew in /usr/local ??

occam65 11y ago
I definitely recommend installing El Capitan first, followed by Homebrew. That will lead to less possibility of the upgrade screwing with your Homebrew installation.

anuraaga 11y ago

Before Apple there was companies' IT's Puppet mangaging away /usr/local from usefulness. Main reason I only use Macports which has never failed me.

sandaru1 11y ago

Just make sure that if there are any launch daemons plist files, those should be root:wheel. Otherwise "launchctl" won't load those daemons.

liveoneggs 11y ago

pkgsrc allows you to build into any directory you want.

rhapsodyv 11y ago

Anyone having issues with macports too?

lectrick 11y ago

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 directory lives, anyway.

tvon 11y ago
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.
- spinlock 11y ago
  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).
  - tvon 11y ago
    It's in /opt, so it's just: PATH=/opt/homebrew/bin:/opt/homebrew/sbin:$PATH I considered a ~/ directory but wanted it available for the rare occasion when there is someone ssh'd into my machine (though I didn't go so far as to update the system-wide shell configs to use it.
berdario 11y ago
It's very common for linux applications to store stuff in $XDG_DATA_HOME (~/.local/share by default) (config files and caches go somewhere else) In my ~/.local I also have a bin/ directory (created by some Haskell tool), so rather than putting stuff in /Users/username/usr/local, I think it might make more sense to recreate the (needed parts of) a unix fs hierarchy in /Users/username/.local There's also ~/LibrarySupport on Macosx, if I remember correctly... but I think that contains user editable configuration files as well

amelius 11y ago

Concepts such as "ownership" and "permissions" have always been a bit of an issue with Apple.

dafstone 11y ago

I installed El Capitan this morning and was expecting to have to do this - I did not. chown stayed owned to me properly, brew functioned as it was before... everything fine.

evolve2k 11y ago
Did you do anything in advance of the install? Eg some people were mentioning earlier to move files out of bin/local before upgrade then copy them back in. Do anything like that?
evolve2k 11y ago
Did you do anything in advance of the install? Eg some people were mentioning earlier to move files out of usr/local before upgrade then copy them back in. Do anything like that?

mapgrep 11y ago

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 libraries for various things. But then it is much more fragile when your system updates. Macports really only depends on a slice of Xcode; from time to time updates will fail to install until you open Xcode and accept whatever new license Apple has bundled with it. But you don't get key components changing out from underneath your packages due to an Apple System Update. My bias here is that I'm a longtime happy Macports user who has tried to use homebrew repeatedly, encountered lots of failed recipes, and gone back to Macports, shaking my head at all the hype around homebrew and the fact that is has somehow become a defacto developer default despite some really sloppy, poorly thought through practices. (And I know that's harsh but for a long time they trashed Macports right in their tagline — "Is MacPorts driving you to drink?" — which just seemed gratuitous.)

outworlder 11y ago
Perhaps the easy of writing recipes, combined with good timing (Ruby was all the rage), is what made people go to homebrew.
joshmoz 11y ago
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 projects and I can't tell you how many times they've made a mess with homebrew, nothing works. Replace homebrew with macports and their problems are solved, rarely to return. Maybe in some cases homebrew installs something a bit faster, but it's rarely a meaningful amount of time and it doesn't make up for all the time spent fixing homebrew when it messes up.
- 11y ago

heimatau 11y ago

This 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 from me. I'm not sure what to do to fix this.

mzs 11y ago
Maybe clear your kext cache. Also boot it single user mode so you can see where it fails.

grandalf 11y ago

Dear Apple: Please start using apt

schmichael 11y ago

Why does homebrew install things as root anyway? Seems like defaulting to installing in your home directory would be a much better practice.

superchink 11y ago
Homebrew does not advocate installing things as root. You can read more about it here: https://github.com/Homebrew/homebrew/blob/master/share/doc/homebrew/FAQ.md#why-does-homebrew-say-sudo-is-bad- https://github.com/Homebrew/homebrew/blob/master/share/doc/h...
- schmichael 11y ago
  Fantastic! Then why is this an issue?
  - s73v3r 11y ago
    They want /usr/local to be owned by you.
    - schmichael 11y ago
      That kind of blows my mind... why not use homedirs instead of abusing global paths!?
      - s73v3r 11y ago
        If it's in a home directory, then the stuff installed is really only usable by that person. I can see some instances where that would be desirable, but I would prefer that the stuff I install is usable by the whole system, even though I'm the only one on the machine.

racl101 11y ago

Ugh, why does Apple try to subdue its customers. If I want root access to a directory that's my problem. They don't need to police what I do.

neckro23 11y ago

By the way, there's a way to create /usr/local without rebooting four times like suggested in the doc: - 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.

mozumder 11y ago

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.

No1 11y ago

Does is still take a few hours to copy over /usr/local during the upgrade like it did during the Yosemite upgrade or has Apple fixed that? I'm glad I read this before moving the /usr/local directory as was previously suggested https://jimlindley.com/blog/yosemite-upgrade-homebrew-tips/ https://jimlindley.com/blog/yosemite-upgrade-homebrew-tips/

ilaksh 11y ago

Using a $150 Chromebook from Walmart with the built-in ssh and my VPSs or xfce via crouton when I feel like it. Works great for web development. No UNIX/linux compatibility problems since it is actually Linux.

l3x5 11y ago

It's easy to get Homebrew and Java running smoothly after the El Capitan upgrade. Read this: http://lexsheehan.blogspot.com/2015/10/el-capitan-homebrew-and-java.html http://lexsheehan.blogspot.com/2015/10/el-capitan-homebrew-a...