GNU stow (http://www.gnu.org/software/stow/)
Completely opposite approaches, but they're both worth looking at - especially if you find MacPorts or Fink too much. (Stow takes an approach similar to Homebrew's use of 'cellar' + individual subdirectories for packages; Rudix provides precompiled binaries.) Rudix in particular is perfect if you just want one or two *nix items quick on a Mac.
Taking ownership of /user/local is completely utterly pointless and just plain bad advice. Copy-and-pasting optimization code from the Gentoo wiki is pointless. Binaries and libs are stripped without must justification, which will (did for me anyway) cause problems when compoing against the libs (eg, easy_install-ing anything against homebrew libs caused problems for me).
There has also been a lot of FUD spread about at the expense of MacPorts which I think is just low class. The anti-Macports complaints basically amount to "I don't understand this, so I'm going to say it's bad".
That said, it's written in ruby, uses github and the homepage is well done, so it will probably be wildly popular.
I can't say I've had any problems with compiling Ruby gems against homebrew besides some settings that needed to be overridden in the MySQL gem, so that hasn't been a problem for me.
I kind of have mixed feelings about the ownership. So far I've been running it in /usr/local owned by my user and haven't had any problems, but I can see the security argument for not doing it. It doesn't feel any different then compiling your own binaries and leaving them in your home directory, something I've had to do on several hosts I've had in the past. (Also: Snow Leopard doesn't install anything to /usr/local by default, so if you're starting from scratch there's nothing to take ownership of...)
Overall, I've rather liked it so far. We'll see if I regret it...
If I really wanted a fleshed out, mature package management system, honestly - I'd install Ubuntu or Fedora.
There no good reason I have yet heard why using /usr/local is bad advise. I assume that since you provided no rationale for your statement you are in fact unaware of one.
But anyway having said this it is merely a recommendation — do whatever you want. The installation guide goes to great lengths to tell you that you should do whatever you want.
Back when I initially made Homebrew I was interested in the greatest goal of maximum awesome O99 CFLAG awesomeness. Now I'm only interested in reliable compiles and the default CFLAGS are pretty sensible. At the time I wouldn't have recommended the project to anyone particularly, but it got popular anyway.
But anyway, I never copy and pasted without reading a bunch first. I spent several days researching the stuff, the Gentoo wiki was a good source.
There is no anti MacPorts stuff in any of the docs anymore. I was never anti MacPorts at all, if anyone will believe me. I just found it to be not a great tool for developers. Homebrew is a grass roots project, at the time it seemed harmless fun to poke fun at the competition. As the project became more popular I took it all out. Now there is just a small gibe that I couldn't resist because it's too good a bit of wit.
Finally, no offence? May I suggest next time you say such a thing you don't immediately accuse the person to whom you mean no offence of being both ignorant and arrogant.
PS with offence, you're an ignorant twat, and probably ugly too.
When I google I mainly find drive-by assertions that it means "UNIX System Resources" (and sometimes "User Specific Resources"). The closest I can find to something real is:
/usr -- originally the directory holding user home directories, its use has changed, and it now holds executables, libraries, and shared resources that are not system critical: X11, KDE, PERL, etc. (The name "Unix System Resources" is a post hoc backronym.)
I really wanted to keep liking Macports, but I got sick of having to install a new perl just to install git, among many examples. The kicker for me was installing pandoc; Macports wanted to download and compile a new GHC, refusing to recognize the one on my system. I let it run for 3 hours and finally killed the install and looked for a better way to do things.
There's a ticket with a lot of activity at http://trac.macports.org/ticket/16830 but afaik there's still no easy way to stop it trying to rip out your new perl 5.10 without manually fixing deps everywhere.
GHC I just installed from a binary package :-)
It seems the anti-homebrew complaints basically amount to "I don't understand this, so I'm going to say it's bad".
The biggest reason I've seen to get rid of Macports in favor of Homebrew is software versions, Homebrew is constantly up to date and I can upgrade software with ease. Not so with Macports.
Within a released version of OS X, they don't tend to break backwards compatibility.
I had nothing but grief from trying to to get a basic (but up to date) LAMP running on any of several OS X (10.5 - 10.6). Life is too short.
If Homebrew develops into a great system in the future, I might boot less to Ubuntu.
Homebrew does just enough to work, and get the job done and attempts to "fit in" with the OS I already have, versus making it's own sandbox off to the side.
While I agree that it would be nice to have seamless integration with the OS, having a completely separate installation helps with things like OS upgrades or when you need to use a different version of a library that is installed by the OS. Does Homebrew do anything to handle that kind of problem?
Like I said in a previous comment, most of the time I'd find myself compiling things by hand into /usr/local anyway.
Please! Use the system's provided libraries. If I need something newer, I'll brew install it myself. For me homebrew strikes a good balance between "compile it myself, damn it" and Macports/Fink. The formula are easy to hack and update (it's simple), and for the most part it just gets ourt of your way.
$ port deps clojure-contrib
Full Name: clojure-contrib @1.1.0
Build Dependencies: clojure
Fetch Dependencies: git-core
$ port deps git-core
Full Name: git-core @18.104.22.168+doc
Runtime Dependencies: rsync, perl5, p5-error
Library Dependencies: curl, zlib, openssl, expat, libiconv
Poor package management isn't the fault of MacPorts; a Homebrew port could be just as poorly designed.
The "variants" infrastructure of MacPorts is one of my favorite parts of MacPorts, it definitely makes it easier to manage interdependencies IMHO.
I ended up creating my own branch of the port tree for clojure bits just because of all the patching needed to avoid this "let me grab a copy of clojure for you" behavior.
I get the reliability argument (i.e., the only way to guarantee stuff builds right is to manage it yourself), but that's a problem with any platform where you might compile things alongside the package manager. So, let me manage that. I don't need a package manager to argue with me about what I want installed.
I use MacPorts, and I've used a bunch of various package management systems, and portage is the only one that lets me maintain servers for > 5 years without reinstalling the whole thing, just upgrading the packages.
The former changes the meaning of the sentence completely.
But otherwise looks great. I would give anything to completely ditch macports.
I'm very suspicious of your story.
All that said, I still boot OS X for specific apps (TexShop, OmniGraffle mostly). Anyway, it is a free world, and certainly OS X is a great choice for development.
I might never boot back into Ubuntu.
Edit: They say it should run on Mac OS X.
I used it for a few months but eventually switched over to homebrew because it's a nice simple system and packages most of the stuff I need.
You have to run a case-insensitive filesystem with pkgsrc (I was anyway) and, like macports, it does not use system libraries so pretty much everything needs to be rebuilt under `/usr/pkg`.
It was worth experimenting with. I might check back on it when I get my new MBP. They have [a lot of packages](http://pkgsrc.se/).