Ask HN: OSX Package Management

I'm not sure it's actually simpler; as a software author, my experience has been:

If I want to release something for the Mac, I post a dmg containing a dragable application; and even the most non-technical user can download and install it immediately. Sparkle provides automatic updates via my website; users gets the latest versions whenever they want them, I don't have to do anything complicated.

If I want to release something for the UNIXes, I provide a set of autoconf scripts and a make-based build system (or one of the recent alternatives, or a Python egg, or a Ruby gem), hope that the package management systems pick it up during their next release cycle, wind up in an argument with Debian over OpenSSL+GPL licensing compatibility, and see my software get shipped with half the featured turned off and a ridiculous number of local hacks applied, including all-too-regularly replacement of a working library dependency with something that doesn't work (but Debian likes it more).

The average end-user doesn't see my updates for months or years, the software is missing features and locally modified, and I have to wonder: Why couldn't I just give them something that they could drag to their applications folder?

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.