Pkgsrc-2015Q1 packages for OS X now available(mail-index.netbsd.org)
mail-index.netbsd.org
Pkgsrc-2015Q1 packages for OS X now available
http://mail-index.netbsd.org/pkgsrc-users/2015/04/20/msg021423.html
5 comments
Really cool to see pkgsrc progressing and staying true to their original aim, being cross platform and useful.
I don't know if it's representative but nodejs is still at version 0.10.36 : https://github.com/joyent/pkgsrc/blob/trunk/lang/nodejs/Make...
This post was supposed to be a troll about them not packaging io.js (they don't).
This post was supposed to be a troll about them not packaging io.js (they don't).
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.
Thanks for the heads up.
Just to follow up on this, these are now available in the 64-bit repository:
$ pkgin se nodejs
nodejs-0.12.2 V8 JavaScript for clients and servers
nodejs-0.10.38 V8 JavaScript for clients and servers
Is there a benefit to this over Homebrew or Macports or am I missing the use case?
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.
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.
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.
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.
> The main benefit to me is that I can avoid homebrew and macports, which are utter garbage.
Would you like to elaborate on that?
Would you like to elaborate on that?
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.
paging Youri/cmacrae and all the other buddies from http://www.saveosx.org/ ;)
Anyway, enjoy! Happy to answer any questions.