1. 11

  2. 8

    Not saying that Apple doesn’t have a problem (slow dir merge of /usr/local?! wtf), but this is yet another reason why I don’t put homebrew in /usr/local. I dump it in ~/.brew/ and it works great.

    Putting homebrew in /usr/local and setting the whole mess owned as your user is just a bad practice and a very poor default on homebrew’s part.

    1. 1

      ~/.brew does sound smart! I think I might try that out. Have you run into any issues with it in there versus in /usr/local, or does everything generally work?

      1. 4

        a few bottles specify /usr/local, so it results in a bit of extra compiling here and there, but generally not too much (for what I install at least).

        In my .profile/.bash_profile/.bashrc I have a couple extra things added.

        # added to profile file
        [ -d $HOME/.brew/sbin ] &&
            export PATH="${HOME}/.brew/sbin:${PATH}"
        [ -d $HOME/.brew/bin ] &&
            export PATH="${HOME}/.brew/bin:${PATH}"
        [ -d $HOME/.brew/share/man ] &&
            export MANPATH="${HOME}/.brew/share/man:$MANPATH"
        # added to rc file
        [ -z "${BASH_COMPLETION}" ] && [ -f $HOME/.brew/etc/bash_completion ] &&
            . $HOME/.brew/etc/bash_completion
        [ -z "${BASH_COMPLETION}" ] && [ -f $HOME/.brew/share/bash-completion/bash_completion ] &&
            . $HOME/.brew/share/bash-completion/bash_completion

        If I am building something outside of homebrew that requires a lib installed with homebrew, I generally just do this first:

        export CFLAGS="-I$(brew --prefix)/include"
        export LDFLAGS="-L$(brew --prefix)/lib"

        Then compile as normal.

        I also exclude $HOME/.brew/ from time machine backups. Those are about the only differences I can recall offhand.

        1. 2

          So one thing I’m kinda leaning towards is to do something like /usr/homebrew vs /usr/local.

          I used to do ~/homebrew but given the differences in upgrading I think it might be better to gate home-brew via the OS X version too.

          So say instead of $BREW_PREFIX, I do $BREW_PREFIX/{10.10,10.9} that way I can just do things that way. I don’t normally upgrade anyway but it would mean its simple to just blitz /usr/homebrew and rebuild in vagrant and tar the thing up.

          Also this post here is also why I hate /usr/local in principle, I get this dudes pissed but 1.8 million files is kinda crazy. Especially if you can rebuild it tar.xz it and nuke it and restore after install. I’m annoyed right now because stuff like mactex installes into /usr/local/texlive, so my old “nuke /usr/local and retry” no longer works.

          Maybe /usr/local/brew. I just don’t like having my home-brew in my home directory, but i guess I don’t really share it so its somewhat of a wash.

          1. 1

            So this is a WIP (aka: I work on it when I get bored) but it works out pretty well so far.



            Is how I hacked it in. Will try this way out for a while and see how it shakes out. One thing I noticed, brew cask doesn’t work at all if its not installed in /usr/local. Eh, oh well.

      2. 1

        I’m not one to argue with anyone claiming that Apple are screwing the pooch lately (my household has a small list of shit-points about recent iOS updates), but I do challenge your veracity in this claim:

        “Putting homebrew in /usr/local and setting the whole mess owned as your user is just a bad practice and a very poor default on homebrew’s part.”

        I don’t agree. This is, finally, precisely what /usr/local/ is for, and anyway: Apple did the recent merge/cleanup thing precisely because they are relinquishing all control over /usr/local - it is now and forevermore for the user to hold their local bins/libs/etc., so that Unix users can continue to have a smooth-running system.

        But, whats your problem with /usr/local? Perhaps you’re not a multi-user Mac setup, so you don’t need to share a cmd-line toolchain, and/or have other methods of maintaining isolation between your Unix toolchain, the OSX bundles, and various other all and sundry packaging systems around (port/homebrew, etc.)?

        Well, here’s why I prefer /usr/local: our development Mac hosts multiple users. There is one homebrew administrator, and a perfectly smooth, functioning development environment where everyone can still, nevertheless, maintain a stable set of homebrew for all local users, who are after all developers. If its really important for a local dev to have isolation of forked common tools, well there’s not many in the gang who don’t already salt their builds of such things with a little –prefix=~/inst and path_prepend(~/inst/) and path_prepend(pkg_config_path, ~/inst/) and so on. But the toolchains for the build-server are common and maintained - everyone is using the same tools.

        I for one, welcome our new /usr/local privileges, and don’t have any problems with homebrews' usage of it. To me its a welcome relief from the bundle warfare thats going on in all other quarters ..

        1. 1

          I don’t agree. This is, finally, precisely what /usr/local/ is for…

          I guess this is where we agree to disagree then. /usr/local has always been to me, machine specific locally installed software, owned by root. That is the main problem I have with homebrew’s default. You have to set the whole tree as owned by the user who runs brew.

          The alternative, I suppose, is running homebrew as root, which seems even worse to me. In addition, I generally prefer to run the configure and make steps of classic building as non-root. Unless this changed recently, I don’t believe homebrew drops privileges for the ‘make’ portion of its operations when run as root.

          So…to avoid those issues, and because my /usr/local is not shared with other accounts anyway, I moved homebrew to a directory inside $HOME. This has actually payed off many times too, as I have had occasion to completely nuke $HOME/.brew/ and start over. I was able to do this without also removing any libraries or software I have installed manually in /usr/local with the classic ./configure;make;sudo make install invocation.

      3. 1

        Interesting read for sure. My Yosemite upgrade DID take about an hour, but I’m guessing this person’s file system was bigger, and internet connection may have been having problems. I’m pretty sure this person is an edge case, but it was probably a crappy way to do things. At least you don’t have to go back and reinstall everything.