Pkgsrc-2015Q1 packages for OS X now available (opens in new tab)

I'll fix that, and add nodejs-0.12 too. 0.10.36 was current at the time that pkgsrc-2015Q1 was frozen for release, but I can build them from our separate pkgsrc-joyent repository.

Thanks for the heads up.

The main general benefit of pkgsrc is that it's cross-platform and, having been around since 1997, now runs on 22 different operating systems.

This means that rather than having to run Homebrew or MacPorts on OS X, rpm or apt on Linux, ports on FreeBSD, dports on DragonFly, cyg-apt on Cygwin, .. - you get the idea - you could instead just run pkgsrc across all of them, and only have to worry about one set of tools and only have to update one software repository. pkgsrc will happily run as an unprivileged user in your home directory if you just want to compliment the system package manager.

For OS X specifically, we provide this binary package repository to make it very easy for people to get started. pkgin has a very familiar interface for people used to other binary package managers, so after a couple of commands to install the tools you can start installing from 11,000+ binary packages quickly and easily.

For developers there is a lot that pkgsrc offers in terms of aiding portability, and due to the large number of supported platforms a lot of infrastructure to support them, but that is a whole topic by itself.

Reversing the question, I don't see that Homebrew or Macports have many benefits over pkgsrc, other than Homebrew is arguably easier to write new packages for (if you know ruby), and Macports has more packages. However I will be glad to admit I'm no expert on either of them, so if there are other advantages please tell me so we can take a look at improving feature parity.

I've never used Homebrew, so can't comment on that, but in comparison to Macports,

Advantages of pkgsrc:

- Everything is a quick binary install. Macports has gotten more and more towards "mostly binary", but I still find it sometimes doing huge compiles.

- Packages generally are installable, and work. Partly due to the quarterly-release model and the all-binary model, I find less breakage (esp. dependency issues) than when doing things in Macports.

- Subjectively, the set of tools feels cleaner.

- Can keep packages synced across OSs, if you use pkgsrc elsewhere (admittedly this is not that common a use case unless you run NetBSD or SmartOS, since typical users of a Linux or other BSD will use the native package manager).

Advantages of Macports,

- More packages

- Often newer packages (e.g. macports is shipping TeXLive 2014, while pkgsrc has some mixture of 2012 and 2013).

- More Mac-specific porting/debugging attention. Somewhat spotty how much, but for example you can choose either X11 or native Aqua versions of emacs, while pkgsrc does only X11 for GUIs.

- Fairly easy to customize packages with the 'variants' system, although in practice I avoid this like the plague because your system quickly ends up compiling things for hours if you use non-default variants.

The main benefit to me is that I can avoid homebrew and macports, which are utter garbage.

There are many other benefits in pkgsrc, including, but not limited to, stable releases instead of rolling release, cross platform support, corporate interest in making the platforms stable, because it's used as a basic building block in Joyent's SmartMachines etc.

But all this pales in comparison to the advantage of avoiding homebrew and macports.

One use case I can think of is if you want to use the same packaged versions between the developer machine (OSX) and your deployment environment (Linux). It not 100% the same but it could help uncover issues before they are deployed. And you don't get the overhead of visualization.