This is a problem that is very easy to solve 5% of. It's the other 95% that's a monster.

If we walk down homebrew's feature list:

- Zero configuration installation. Copy the contents of this directory to /usr/local. Homebrew is now ready for use.

This is how DarwinPorts started out, too. The problem was that eventually the implementation needed to run some pieces of native code, and a build process was born.

- Or… install anywhere! You can actually stick this directory anywhere. Like ~/.local or /opt or /lol if you like. You can even move this directory somewhere else later. Homebrew never changes any files outside of its prefix.

Fink and MacPorts do the same thing. However, moving UNIX software from the prefix it was built with will rarely work.

- The GoboLinux approach Packages are installed into their own prefix (eg. /usr/local/Cellar/wget) and then symlinked into the Homebrew prefix (eg. /usr/local). This way packages can be managed with existing command line tools. You can uninstall with rm -rf, list with find, query with du. It also means you can easily install multiple versions of software or libraries and switch on demand.

This is what MacPorts does, too. Look at /opt/local/var/macports/software -- every package in their own versioned subdirectory, hardlinked to /opt/local and managed automatically by MacPorts. You can have multiple versions installed at once (but only one activated).

You don't have to sudo It's up to you. We recommend not--see the relevant later section.

MacPorts used to not require sudo, but the fact is that users wanted things like launchd startup scripts installed and daemon users created. You can still run MacPorts as non-root, but some things (like creating a new user for postgresql) will break.

In later versions, MacPorts supports acquiring/dropping privileges as necessary to run non-root when possible.

- Easy package creation. Packages are just Ruby scripts. Generate a template with ...

In MacPorts, ports are just Tcl scripts with a very clean DSL.

- DIY package installation MacPorts doesn't support the beta version? Need an older version? Need custom compile flags? The Homebrew tool-chain is carefully segregated so you can build stuff by hand but still end up with package management.

MacPorts supports your own local port files. Copy over the port file (port cat <portname>) to a new local directory, tweak it a bit, and run 'port install' from the directory. Done.

- No duplication. MacPorts is an autarky -- you get a duplicate copy of zlib, OpenSSL, Python, etc. Homebrew isn't, and as a result everything you install has less dependencies and builds significantly faster.

MacPorts and Fink used to try to leverage the operating system dependencies, but the fact was that Apple would break those dependencies in minor releases and in ways that were incompatible with the user-installed software.

More importantly, the dependencies would grow stale and often be missing requested functionality, leaving users in the lurch and requiring the introduction of "duplicate" dependencies to the port system.

- Fork with Git The formula are all on git, so just fork to add new packages, or add extra remotes to get packages from more exotic maintainers.

MacPorts supports portfiles places in arbitrary file://, http://, rsync://, svn://, etc locations. If you want to run your own portfiles, you can do so through a myriad of equivalent mechanisms (including git).

I'll stop here. The fact is that this problem space is an unexpectedly deep rabbit hole, and it's very easy to peer down it and think you've solved it, when in fact you have no idea how deep the rabbit hole actually goes.

MacPorts, Fink, apt-get and friends don't do things in a certain way because they're stupid, which seems to be so blithely implied in the homebrew documentation. They do these things because decades of experience have demonstrated the depth of the rabbit hole and the requirements necessary to provide a generally useful solution.

There's enormous room for improvement, but it's not going to happen with a project like homebrew following the exact same footsteps of the projects that came before -- and making the exact same mistakes.

Of course, the real problem is that building and maintaining a large package tree takes a ton of effort, and it's not very interesting work. I think that this is the real reason why package management is lacking on OS X--no one has any financial incentive to make it better. With Canonical and Red Hat, they literally have no product without a healthy package tree. So they pay a lot of people to package software. There is no corresponding situation in OS X. The vast majority of their users don't give a hoot, so Apple is not interested.

I think there is a modest but extremely unglamorous business opportunity here. Get a healthy FOSS package tree going for all arches on OS X and charge people $1 a month for access. (AFAICT this is allowed by the GPL: http://www.gnu.org/licenses/gpl-faq.html#DoesTheGPLAllowDown...)

MacPorts can actually generate dpkg, rpm, and even Installer.app packages, but there hasn't been the resources or interest in maintaining a tree of binary packages. There has also been work into creating a dpkg-alternative via xar.

Fink produces dpkg packages as well, but has resource constraints in producing up-to-date trees of binaries.

I think there is a modest but extremely unglamorous business opportunity here ...

Definitely allowed, but could you prevent users from simply copying your packages to an open repository (ala CentOS vs RedHat)?