My understanding is quite the opposite. There are a number of trivial differences between MacPorts and Homebrew - for example, MacPorts recipes are written in Tcl, Homebrew's are written in Ruby, MacPorts puts things in /opt/local, Homebrew puts things in /usr/local/Cellar, MacPorts gets its metadata with rsync, Homebrew uses Git. But there is, as far as i know, only one non-trivial difference: MacPorts links everything against versions of libraries that it has installed, whereas Homebrew links them against the ones supplied by Apple.
The Homebrew maintainers think that linking against Apple's libraries is better, because you need to install less stuff.
The MacPorts maintainers used to agree, several years ago, and used to do just that. Then, Apple released a software update which changed some libraries and broke everyone's MacPorts installations. So then they changed their mind. Now, they think that linking against their own, coherently managed, set of libraries is better, because Apple can't break stuff.
To me, Homebrew just looks like an exercise in reproducing others' work without learning from their experiences. I don't see any advantages to it myself.
Less fundamentally, there's also quite a difference in the number of packages. MacPorts's homepage indicates that they have 18530 ports. An ls|wc in Homebrew's repository indicates that they have 2802 formulae. That said, i suspect that 95% of what people actually need is in the collection that Homebrew has.
I don't think Homebrew was so much reinventing the wheel, as it was trying to create a modern replacement in an era when MacPorts/DarwinPorts was stagnate and Fink was in a similar state of upheaval.
I remember having issues getting Fink and MacPorts to run correctly in the early days of Snow Leopard, which was frustrating if you needed a library. Homebrew came in, was easier to install and had less legacy code issues.
As for tbe package counts, I'd say most of those packages are probably relics from the PPC days. I was hesitant to switch to Homebrew, but in really do think it has a better implementation.
I did try MacPorts for the first time in over a year on a new system recently, and it has improved dramatically.
But really, package management systems are all about reinventing the wheel. I'm glad both projects are active.
I thought like what you describe at first, but after using it, I realized it was just much more productive because of the simplicity. In homebrew, if a linked lib breaks, it's pretty easy to fix by simply reinstalling, and it doesn't happen very often. It's also trivial to change build options. So, basically, it's more disjoint, but because of this, it moves much faster and is way more flexible.
The Homebrew maintainers think that linking against Apple's libraries is better, because you need to install less stuff.
The MacPorts maintainers used to agree, several years ago, and used to do just that. Then, Apple released a software update which changed some libraries and broke everyone's MacPorts installations. So then they changed their mind. Now, they think that linking against their own, coherently managed, set of libraries is better, because Apple can't break stuff.
To me, Homebrew just looks like an exercise in reproducing others' work without learning from their experiences. I don't see any advantages to it myself.
Less fundamentally, there's also quite a difference in the number of packages. MacPorts's homepage indicates that they have 18530 ports. An ls|wc in Homebrew's repository indicates that they have 2802 formulae. That said, i suspect that 95% of what people actually need is in the collection that Homebrew has.