&#62; MacPorts is an autarky -- you get a duplicate copy of zlib, OpenSSL, Python, etc. Homebrew uses what is already there, and consequently, most stuff has zero dependencies and builds faster.<p>MacPort's self-sufficiency is its strength. Apple's system is managed by Apple, via Software Update. Depending on and modifying that system is foolhardy. What happens when the next point upgrade of OS X updates a library to a non-compatible version? Or what if you need ruby 1.8.7, but Leopard's ruby is at 1.8.6 (1.8.7 was a large release)? Your package system doesn't talk to Apple. Apple's update either breaks you, or your updates break OS X.<p>In fact, MacPorts once linked to OS X's libraries, but they found out how brittle this was, and switched to the current system.<p>OS X is not a Linux distribution, and it is not organized and defined by its package management system. If you want the flexibility of an open source Unix package system in OS X, you have to build one separately from Apple's Emerald City. The thing is, you can, and it works pretty well.<p>The problem I see most people having with the MacPorts / OS X duality actually stems from improper management of their shell's PATH. One way to manage namespace collisions is this: place MacPorts bin directories below the system PATH:<p><pre><code>    export PATH="/usr/local/bin:$PATH:/opt/local/bin:/opt/local/sbin"
</code></pre>
and then create symlinks in /usr/local/bin to specific MacPorts executables that you would like to have on the top of the search stack. That way, you'll use Apple's binaries by default, and then you can cherry pick the MacPorts binaries that you would like to use in place of OS X's defaults. The inverse of this works quite well too.<p>&#62; Dependency resolution and updates are basic or not working yet.<p>I'm sure this is in the works, but my feeling is that managing dependencies and updates are the raison d'être of a package management system. Without this, you just have an installation management system; a shortcut around `make' and `ln'.