6

I'm about to switch over to the Homebrew package management system, and almost everything looks very simple. However, I've been using this computer for a while, and so I already have a bunch of stuff in /usr/local. I'm OK with deleting almost all of it, as there are formulæ for almost everything in there. However, it's the "almost" that's leading to my current confusion. There are some executables—including published ones, small personal scripts, and even TextMate's mate tool—in /usr/local/bin which aren't available through Homebrew. The Homebrew Tips 'N' Tricks page suggests using ./configure --prefix=/usr/local/Cellar/foo/1.2 && make && make install && brew link foo, but this is only a useful suggestion if there's something I'd like to actually build, rather than a simple binary or a symlink to something local.

My question, then, is how to deal with unmanaged software and Homebrew simultaneously. I see a few possible approaches:

  1. Mix the two freely. I can't tell if Homebrew will tolerate me dumping unmanaged binaries and symlinks in /usr/local/bin; my guess is that it will work for now, but just lead to problems down the road. However, I also see that Homebrew's supposed to be flexible with existing file hierarchies. I'd be curious to hear what the official line on this is. Nevertheless, it's not clear that it's an attractive approach.
  2. (Ab?)Use the official system. Create empty /usr/local/Cellar/foo/1.0 directories, copy the binaries/symlinks in there, and then brew link foo. This will make symlinks be twice-indirected, but that doesn't seem like a real problem. This seems like the best approach to me, but not having used Homebrew, I'm not sure about the drawbacks. Is this going to cause long-term problems when, for instance, upgrading formulæ, or when new overlapping formulæ are created?
  3. Just don't mix the two. There are two approaches here:
    1. Put my personal binaries/symlinks in another directory. I'm not sure what the best location is (~/bin? ~/usr/bin? Something else?), but it solves the mixing problem by punting on it.
    2. Put Homebrew in another directory (e.g., /usr/homebrew/). This solves the problem in the same way as 3.1. The disadvantage is that I'm putting Homebrew somewhere nonstandard, which seems like it'll just cause a series of tiny minor headaches in the long run.
  4. Something else that I don't know about or haven't thought of.

What's the best way to do this? Is there an official one? Are there obvious flaws or benefits to any of these approaches that I haven't thought about?

Improve this question
1
  • This is the main reason I use Macports (or Fink) the directories they manage are their own and only they manage them (/usr/local is for selt built code which I have to manage). /usr/local is a problem as gcc and others always read from there and so you lose control.
    – mmmmmm
    Commented Dec 28, 2011 at 16:34

2 Answers 2

Reset to default
6

I use 1.

I just compile my software using /usr/local as the prefix and I'm done. I had no problem so far. I don't know whether I'll experience problems, but I started ~1y ago and so far so good.

However…

If I'd have to start again today, I'd follow 2 (which I didn't know at the time). That way it's easy enough to know where everything is and what, exactly, the software has installed (since the hierarchy for /usr/local/Cellar/foo/1.0 is something like

bin/      etc/      include/  lib/      share/

)

3 doesn't seem worth.

Improve this answer
1

Homebrew tolerates non-homebrew things in /usr/local just fine. You can confirm that all is well by doing brew doctor - if anything is likely to conflict, homebrew will warn you.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .