Sign up ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

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?

share|improve this question

5 Answers 5

up vote 14 down vote accepted

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.

share|improve this answer
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 '10 at 20:27
@Babu - According to brew, you should proceed with caution – Peter Ajtai Sep 19 '12 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 – Mark Sep 19 '12 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.


share|improve this answer
Looks like it is also possible to install homebrew in ~/.homebrew. Would it still interfere with MacPorts if it is installed there instead? – Behrang Mar 24 '12 at 3:14
Any other location than /usr/local should be okay. – Raim Mar 25 '12 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 '13 at 0:52
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. – Raim Dec 14 '13 at 15:34

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.

share|improve this answer
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 '10 at 13:52
MacPorts as good reasons not to use /usr/local, see – Raim Feb 18 '11 at 20:07
@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. – Charles Stewart Feb 18 '11 at 21:12
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 '14 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. – Charles Stewart Nov 6 '14 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!

share|improve this answer

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.

share|improve this answer
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 '14 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 '14 at 14:24
Correct. It only prevents build-time problems, not run-time problems either (but those are very rare). – neverpanic Nov 9 '14 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 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 at 14:27

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.