I have MacPorts installed on my iMac with a fair number of ports installed.

I'm interested in trying out Homebrew, though, as I've heard many good things about it, and because I've noticed that it contains more up-to-date versions of several of the tools that I use.

But can the two coexist on the same machine, or do I need to uninstall MacPorts entirely first?

Also, if the two can be installed at the same time, will they be completely independent of each other? One of the features of Homebrew is that is doesn't reinstall new versions of things which are already included in the system (e.g. python). Does this also extend to it not installing versions of things which are already maintained by MacPorts?

What happens if I then subsequently uninstall MacPorts?

6 Answers 6


They will not coexist well together. The Apple gcc looks in /usr/local for some things. This means that a macports compile could find something the porter did not expect. See macports mail lists and bugs for examples of things found in /usr/local.

  • 5
    I've only had a very cursory look at homebrew, but if you changed the default install location for homebrew from /usr/local to something like /opt/homebrew/usr/local, would that problem be avoided?
    – Babu
    Sep 12, 2010 at 20:27
  • @Babu - According to brew, you should proceed with caution Sep 19, 2012 at 18:21
  • @babu - possibly but there will be issues with which of homebrew or macports is forst pn the path and the other picking up those executables also I suspect the ports of either system aren't fully tested using another path
    – mmmmmm
    Sep 19, 2012 at 20:51

I gave another answer on a similar question:

Homebrew will cause problems when building software from source if it is installed in /usr/local. This is the default, which is a bad choice as this path is in the default search path of compilers and other tools. Therefore builds from other packaging software might pick up the wrong dependency, using Homebrew's version instead of their own.

Years ago, in the very beginning of the project, even MacPorts was using /usr/local. But it turned out not to cooperate with other tools as is documented in their FAQ. Unfortunately Homebrew developers didn't want to hear about prior experiences and ignored such facts...

In general, it is usually better to stick to one tool only to avoid all problems. MacPorts is doing their best to patch out any harcoded paths, e.g. to /sw which is used by Fink. So usually it will work, but having anything installed in /usr/local will definitely cause problems for it.


  • 1
    Looks like it is also possible to install homebrew in ~/.homebrew. Would it still interfere with MacPorts if it is installed there instead? Mar 24, 2012 at 3:14
  • 1
    Any other location than /usr/local should be okay.
    – raimue
    Mar 25, 2012 at 11:21
  • Will MacPort and Homebrew coexists well if one would install Homebrew to /opt/local, where MacPort is installed?
    – Adam L. S.
    Dec 13, 2013 at 0:52
  • 1
    You should not install other software manually into /opt/local when MacPorts is already installed there. It will definitely interfere as you place files there that are unknown to MacPorts, leading to conflicts when installing ports.
    – raimue
    Dec 14, 2013 at 15:34

According to the MacPorts FAQ:

Note that starting with 2.3.0, MacPorts can automatically hide /usr/local (and all other files a port does not depend on) from ports' build systems. This feature is called trace mode and is activated by providing the -t flag to port, e.g.

sudo port -t install <portname>

This is relevant because according to the Homebrew Installation Page:

One of the reasons Homebrew just works relative to the competition is because we recommend installing to /usr/local. Pick another prefix at your peril!

Therefore, and with little personal experience, I theorize that always using the -t flag for MacPort installs should prevent most problems of having MacPorts and Homebrew coexist on the same system. To address your last question: I don't see any reason why uninstalling MacPorts would cause any problems.

  • Be aware that you will be suffering from a significant performance penalty. But in general, this should work in almost all cases.
    – neverpanic
    Nov 5, 2014 at 17:55
  • Thanks for pointing out that caveat @neverpanic. I assume said performance penalty only affects the time to install the port and has no effect on any runtime characteristics of the installed port. True?
    – webappzero
    Nov 8, 2014 at 14:24
  • Correct. It only prevents build-time problems, not run-time problems either (but those are very rare).
    – neverpanic
    Nov 9, 2014 at 19:36
  • In practice, I failed to remember this requirement of always using the trace flag. Therefore, I don't recommend this practice to others unless you are confident you will use -t consistently.
    – webappzero
    Oct 4, 2015 at 13:38
  • If you don't want to remember it, you could write a wrapper script or shell alias (but be aware of the interaction between sudo and shell aliases) to always pass it for you. Note that El Capitan currently breaks trace mode. I'm working on a workaround.
    – neverpanic
    Oct 5, 2015 at 14:27

I used to think that worries about what the Gnu build tools will make of /usr/local were verging on paranoid. The build tools expect there to be lots of things there: in the good old days before package managers (I joke), we compiled whatever to /usr/local. But while Autoconf usually does figure out issues, the sheer build complexity of many open-source projects does cause problems and these problems can be hard to back out of when you get into difficulty.

But the risk of trouble with Autoconf finding something it shouldn't under /usr/local needs to be balanced about the maintenance nuisance having two, three, or four different different copies of Perl, Tcl, and Ruby, each with different coverage of their different package libraries. Unpleasant.

Since my experience with MacPorts and Fink has typically been exasperation caused by exactly this, and at some point switching to compiling the old-fashioned way to /usr/local, I was pleased to see that Homebrew didn't mess about with that. I tried configuring MacPorts to install to /usr/local, but MacPorts goes out of its way to make that difficult. I understand that the motivation is to make life easier for themselves when dealing with cries for help on their mailing list and bug tracker: please be aware, though, that while we should respect the effort of volunteer packagers and treat their time as precious, their debugging convenience is not the only sort of simplicity that affects you, as a user.

Homebrew, in this respect at least, does things the way they used to be done, and MacPorts tries not to interfere. If you are willing to document which packages you need with Homebrew, and wipe /usr/local clean and reinstall in case of difficulties, then you can always back out in the case things go badly wrong. And once you realise that problems in /usr/local do not generally carry the risk of permanent damage to your machines, you may feel freer to take risks.

I'll just note how much worse packaging is on OSX than FreeBSD: Apple does not really seem to care about the usability of its BSD subsytem, because this is a problem they could help with.

  • Well, my question is asked from the perspective of a dumb user that is just using the package manager to "get stuff". It's not at all certain that I would be able "to figure out things a bit [my]self if things go wrong." Still, upvote anyway for the extra clarification. Thanks!
    – Rich
    Nov 26, 2010 at 13:52
  • 2
    MacPorts as good reasons not to use /usr/local, see trac.macports.org/wiki/FAQ#defaultprefix
    – raimue
    Feb 18, 2011 at 20:07
  • 3
    @Raim: Good reasons for them - it is pretty much a trade off between their bug-tracking convenience and the simplicity of the install on the user's machine. I care about the latter. Feb 18, 2011 at 21:12
  • 2
    The number of things that can go wrong because somebody (or something) installed a copy of $lib in /usr/local is endless. Architectures, versions, configured features and flags, partial installations, outdated installations with security issues, and and and will cause problems. Sure, go ahead if you know what you're doing, but don't file bugs about it. Experience shows that people file bugs anyway, and that's exactly the reason why trace mode (-t, see below) exists and why avoiding /usr/local is the default recommendation.
    – neverpanic
    Nov 5, 2014 at 18:00
  • @neverpanic - My opinion on the risks of compiling everything to /usr/local have changed since I wrote this answer, mostly because build complexity of typical open-source projects just goes up and up, and Autoconf issues aren't getting any easier to sort out: at the least, "verging on paranoid" is unfair. I still don't like the Macports "own private build universe" approach, though, and it deserves emphasising that simplicity of mailing-list interactions is not the only kind of simplicity the end user should worry about. I'll add caveats to my answer. Nov 6, 2014 at 8:31

While installing homebrew on a computer where I've been using ports for years, here is what I can read:

Warning: You have MacPorts or Fink installed:

This can cause trouble. You don't have to uninstall them, but you may want to
temporarily move them out of the way, e.g.

  sudo mv /opt/local ~/macports

Be careful!


webappzero's sudo port -t ... solution should help. To be honest, I run with Fink, MacPorts and Homebrew all at once, with deference to MacPorts (for now anyway), and only using either of the other two to install things I can't get from MacPorts. I've run into very few difficulties this way, even before learning the port -t trick. If you're trying to use multiple package managers to maintain complex development and server environments, though, you're probably in a for a world of discomfort at least. Pick one, and avoid the others but for something you desperately need from them, and put the main one earlier in the path.

If what I'm hearing is true about Apple going to forbid things to install into /usr/ other than Apple's own (or maybe they're already doing that in El Crapitan, which I'm avoiding "up"grading to until after more problems with it are resolved), I suppose that will mitigate the issue after Homebrew defaults to using something else – whether we agree with Apple's heavy-handed approach or not.

In the end, I like the idea of confining Apple's own ports to its own tree, I just wish it wasn't /usr/. I'd rather they'd used /System/bin/, etc., etc., to isolate their own stuff, so I could bypass it with up-to-date, community-maintained software more easily.

You must log in to answer this question.

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