MacPorts vs. HomeBrew

A friend asks whether they should use [MacPorts][MacPorts] or [Homebrew][Homebrew].

What these are, are ways of installing Unix (Linux or BSD) software on your Macintosh in a way that they get updated. This is useful if you need to customize your [(L)AMP][LAMP] stack, or process a document in [LaTeX][TeXShop], or do [graphing visualization][GraphViz] or [-code optimization][KCacheGrind]… there are a lot of uses and having a consistent Linux-like or BSD-like tree of libraries and applications is usually the best option.

I use MacPorts and I’ve used [Fink][Fink] in the past. I never tried Homebrew

[MacPorts]: http://www.macports.org/ “The MacPorts Project”
[Homebrew]: http://mxcl.github.com/homebrew/ “Homebrew: MacPorts driving you to drink? Try Homebrew!”
[Fink]: http://www.finkproject.org/ “Fink”
[LAMP]: http://en.wikipedia.org/wiki/LAMP_(software_bundle) “LAMP (software bundle)—Wikipedia”
[GraphViz]: http://www.graphviz.org/ “Graphviz: Graph Visualization Software”
[KCacheGrind]: http://kcachegrind.sourceforge.net/html/Home.html “KCacheGrind”
[TeXShop]: http://pages.uoregon.edu/koch/texshop/ “TeXShop”
Fink is great. It is based on Debian Linux [apt-get][apt] and has [a nice GUI tool][FinkCommander] for seeing and maintaining packages. The reason I switched was simply because it would take **forever** to install some new software (like kCacheGrind) because the dependencies would be so large and I’d be compiling everything since I needed access to the “unstable” branch for some stuff and only the “stable” branch was available as binaries, and that would often fall out of maintenance (every time a new version of Mac OS X came out). The combination of the two meant that I’d be required to compile, and compile, and compile, and often something would fail in the middle because their package maintenance was spotty (my opinion).

The BSD version of software package management has always been the Ports system, so it was only natural that since Mac OS X is modeled after BSD (via the Darwin kernel) that someone would make Ports for it. That became DarwinPorts, which is now known as MacPorts. I found that compile times are longer for some stuff, but shorter in others because it is much easier to avoid optional packages (via port files). On the other hand package maintenance seemed a little better and failed compiles seem to occur much sooner, than later. Also, there were packages available that were not available or never seemed to work in Fink. All in all it seems a wash since both Fink and MacPorts have complete enough package trees.

It’s hard to evaluate from here whether a switch to Homebrew is worth it. Here are some things that sound attractive about Homebrew.

1. Their website is prettier and more mac-like. Looks to me morale is much better than the other package trees because of it. :-)
2. I like the **idea** of depending on existing Mac OS X installed packages since that will drastically reduce compile times and minimize redundant libraries
3. The [git][Git] repository tied to a [SQLite][SQLite] database is clever. Nothing wrong with CVS and port files, but I appreciate clever. I’m sure if I want to be maintaining my own version from scratch with custom compile files, then this is actually a superior idea. [GitHub][GitHub] being that repository puts everything in the open. I can also see the appeal if you are a Ruby developer since the scripts are in that language.
4. It sounds like Homebrew “formulas” are easier to modify that MacPorts port files if you are noob. The added advantage is you can fork them in Git no problem, whereas your modified MacPorts portfiles will live on an island.

But here is my reasoning for holding back:

1. It’s a younger package tree than MacPorts or Fink. Younger means less packages, and perhaps a package you need is missing. Specifically, Homebrew has less packages than even Fink’s stable tree (not even close to MacPorts or Fink’s unstable tree). This means you’re probably going to have to supplement them with MacPorts or Fink anyway. If not, how tested are these packages? I’m not looking forward to begin someone’s guinea pig.
2. Homebrew takes over /usr/local by default. I don’t like this because you are asked to hand install stuff into /usr/local. There is a long unix-tradition that speaks to this effect. This means you might run into conflicts with stuff you installed by hand, and you can’t reset the entire management tree with a simple command. It also means that on my particular install /usr/local precedes /opt/local (MacPorts) and /sw (Fink) in my path. Guaranteed that a Homebrew software will be always used in precedence to either. While I’m sure you can install it elsewhere I wonder what sort of developers would choose /usr/local, what is the reasoning for a package maintenance system that isn’t defacto standard (like [yum][yum]+[RPM][rpm] on Fedora, apt-get on Debian, Ports on BSD) to decide to go head-to-head with user-maintained software?
3. By default /usr/local gets its perms reset to the user. By convention, /usr/local is supposed to be set so all users of the systems can use it. Clearly the mentality is a single user computer.
3. [/usr/local][usr-local] and “prefer Mac OS X packages” by default is not a new idea, I’d say it is the first idea that pops into any port maintainer’s brain—[Rudix][Rudix] does the same thing, for instance. This sort of thing works great until Apple upgrades their operating system and all your dependencies break. Even if not, you are depending on some drastically old libraries. Apple lags the latest libraries by a noticeable margin—I can’t remember how long they were on PHP 4 and Apache 1 before they switched (did they? I hope so).
4. In fact, MacPorts used to prefer Mac OS X packages by default, [but switched to using their own libraries][MacPorts FAQ]. While I like the *idea* of using existing system libraries, MacPorts did this also and gave up on it. Why? What lessons can be learned here? Nothing is without its tradeoffs, so what are they? My guess is you’re going to find out with Lion. Homebrew came into existence shortly after the previous system update (Snow Leopard), so they’ve never had to deal with the rug being pulled under them. I’ve seen it, and the frustration of the binaries never working is why I (and many others) migrated from Fink to MacPorts.
4. Homebrew formulas have no use-history like apt-get or portfiles. There are historical changes like dealing 32-bit/64-bit binaries, making a default install tree, support for downstream and upstream package dependencies (versioning), handling local changes, conditional compilations, etc. Not sure Homebrew has dealt with them all. I suspect growing pains.
6. I’m a lazy person. I let good enough win over better any day.

In other words, the only thing I find in favor of Hombrew is the only thing I will grant is the decision to use Git/GitHub and SQLite, since those options didn’t exist when the other package systems were invented.

But, all my negatives point to one great reason to avoid Homebrew: attitude. The attitude is “we’re better and here is why” without even a hat tip to why their predecessors opted on a different strategy. Why re-invent the wheel? When you don’t acknowledge your failing (you don’t have to on your homepage, but there should be a healthy discussion **somewhere**), then I am go running. Instead I see a lot of arguments of opinion spun as arguments of fact, that implies that a switch to Homebrew will end up [tasting more like Kool-Aid][Drink the Kool-Aid].

I remember having both Fink and MacPorts around on the same machine for a year, other than redundant files, there were no problems. I’m sure if you can live with Homebrew being the preferred libraries and software, you can install Homebrew and MacPorts at the same time—preferring Homebrew and supplementing it with MacPorts. Maybe I’ll try that if enough of you convince me. :-)

For my friend, I recommend he either uses MacPorts, or installs Homebrew (in a directory like /usr/brew) and supplementing any missing packages with MacPorts (instead of messing with the formulas). If he were a Rails developer, I’d say go all-in with Homebrew. The same things that attracted him to Ruby on Rails will probably attract him to Homebrew. He doesn’t need me to point out the obvious.

[GitHub]: https://github.com/ “GitHub: Secure source code hositng and collaborative development”
[Git]: http://git-scm.com/ “Git: Fast Version Control System”
[SQLite]: http://www.sqlite.org/ “SQLite”
[Rudix]: http://rudix.org/ “Rudix: Unix ports and packages for Mac OS X”
[MacPorts FAQ]: http://trac.macports.org/wiki/FAQ#ownlibs “Why is MacPorts using its own libraries?—MacPorts FAQ”
[usr-local]: http://hivelogic.com/articles/using_usr_local/ “Using /usr/local”
[Drink the Kool-Aid]: http://en.wikipedia.org/wiki/Drinking_the_Kool-Aid “Drinking the Kool-Aid—Wikipedia”
[yum]: http://yum.baseurl.org/ “YUM: Yellow Dog Updater Modified. Based on a Linux port for MacOS (pre-Intel) days called Yellow Dog Linux”
[rpm]: http://en.wikipedia.org/wiki/RPM_Package_Manager “RPM Package Manager—Wikipedia. Red Hat’s copy of slackware’s system. Very popular management in the Unix world when paired with yum”
[apt]: http://en.wikipedia.org/wiki/Advanced_Packaging_Tool “Advanced Packaging Tool—Wikipedia. Single-handedly responsible for the popularity of Debian Linux, IMO.”
[FinkCommander]: http://finkcommander.sourceforge.net/ “FinkCommander”

11 thoughts on “MacPorts vs. HomeBrew

    1. wtfbro

      Who writes an article comparing two package managers without having used both of them. This is trash-writing and just litters the web. Thanks for wasting my time.

      Reply
  1. Evan Goer

    Package management options are just not all that great in OS X compared to its cousin OSes. I do prefer MacPorts over Fink, since as you say, MacPorts seems to have the edge in package maintenance & availability. Though the difference is not huge.

    I don’t understand the love for Homebrew at all. I could live with the arrogance & trash-talking about the older package managers if Homebrew actually was a major leap forward. But blindly depending on system Perl, system Python, etc. is a serious design flaw, not a feature to be bragging about. Ditto for taking over /usr/local. I’ve seen Homebrew fanboys advocating doing things to your UNIX system that would just make your jaw drop. Do not want.

    Reply
  2. Abel

    Thanks for your assessment, Terry. I’ve resisted the installers (MacPorts & Homebrew) for over a year, building my own versions of utilities as necessary, but I’m considering ease-of-use these days and had a tough time weighing my options.

    Thanks again!

    Reply
  3. Olivier

    Reason 6 above for holding back is a big one in my opinion. Homebrew works fine for installing a bunch of packages, each with a couple of dependencies which in turn have another few dependencies. But before you know it you have some 50-60 ‘formulae’ installed. There comes a point when you want to get rid of one or more of you earlier packages, so you issue a “brew uninstall pkg” and it’s gone. Now you’re left with all it’s (sub)dependencies still installed, which could very well also be dependencies of other packages, but maybe not. Your only option is manually removing each and every dependency, or writing yourself a crude script to test out all the possible connections — something that would become really inefficient if you have a lot of stuff installed.

    I’m sure the homebrew developers are looking for ways to solve this problem elegantly and smartly, but for now this could be a good reason to steer clear of homebrew for the time being.

    Reply
  4. G. Clifford Williams

    You left out pkgsrc (http://www.pkgsrc.org)

    I run homebrew and pkgsrc (together) because they allow me to install what I want without needing to be a privileged user. HomeBrew is pretty restrictive as to what they allow in. Pkgsrc is much more liberal being that it’s the main mechanism for installing third party software on NetBSD and a few other systems. My instructions for getting them to play nicely together are on my blog at: http://www.notadiscussion.com/2011/06/pkgsrc-alogside-homebrew.html

    Reply
  5. Mukund

    I have been using macports for a long time and every time I want to be destructive, I can trash /opt/local and nothing’s hurt. /usr/local is not a good idea. fink was good about 5 years ago. :)

    Reply
  6. Daniel Worrall

    What a good blog post. I am just starting out with package managers on OSX, I have friends who are ‘Brew fans and an old School-er Mac user who swears by MacPorts. I have been getting to grips with Macports Your blog has broken down a few barriers for me and along with the comments it is good to have some opinions on why ‘Brew is not the way to go!

    Reply
  7. Pingback: Homebrew: software per il Mac fatto in casa | MelaBit

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>