3 ms·

Has anyone tried this? My two worries are that: (1) OS X is different enough from NetBSD and pkgsrc's assumptions about how the OS is set up and what kind of b

Has anyone tried this? My two worries are that: (1) OS X is different enough from NetBSD and pkgsrc's assumptions about how the OS is set up and what kind of base installation is available [compilers, linker and what not), so that I can't really expect that the average package will actually work; and (2) It might not have the packages I need (possibly because of licensing issues). Homebrew, which I am using, is license-agnostic, whereas I think NetBSD excludes (L)GPL code? A casual browse through the package list [1] shows me that it has many things I use, but also lacks many things I use. For example, it lacks Discount (the Markdown processor), rbenv (what I use to easily switch between Ruby versions), rbbuild (what I use to easily install Ruby versions), Node, Elasticsearch, Redis, Riak and Proctools (pkill etc.). Not too bad, but it means that any switch away from Homebrew will involve a lot of work with very little upside. (Also, I notice NetBSD makes the same mistake as some Linux distros in creating packages for Ruby gems.) As a side note, I know this is the *BSD way and all, but remembering a path to "cd" to in order to run "bmake && bmake install" seems silly in this day and age. Is there really no command-line tool that integrates this process, as well as the task of keeping the ports tree synced? "brew install" is so much simpler. [1] http://ftp.netbsd.org/pub/pkgsrc/current/pkgsrc/README-all.html http://ftp.netbsd.org/pub/pkgsrc/current/pkgsrc/README-all.h...

peripetylabs 14y ago
So far, I haven't seen any OS X-specific problems with the build process, everything works fine. The pkgsrc documentation says OS X is officially supported. The pkgsrc-wip project has packages for some of those projects you're looking for: Discount: http://pkgsrc.se/wip/discount http://pkgsrc.se/wip/discount Node: http://pkgsrc.se/wip/node http://pkgsrc.se/wip/node Redis: http://pkgsrc.se/wip/redis http://pkgsrc.se/wip/redis Riak: http://pkgsrc.se/wip/riak http://pkgsrc.se/wip/riak More about pkgsrc-wip: http://pkgsrc-wip.sourceforge.net http://pkgsrc-wip.sourceforge.net To simplify the build process, there is a pkgsrc "front-end" called pkgin: http://pkgin.net http://pkgin.net Hope that helps.
- lobster_johnson 14y ago
  Thanks, that's helpful. In general the entire system seems rather... antique. It doesn't give me a happy, fuzzy feeling inside. The reason is that I'm not a Unix geek, not in the ways this system wants me to be. Oh, sure, I know the tools; I've written hundreds of bash scripts, I've done my share of C/POSIX programming, I know my way around Make and GCC and so on. But I don't want to do those things. What's so great about Homebrew is that the recipe files are built against an API, which coincidentally is a simple programming language (Ruby). Pkgsrc seems to be based on makefiles, which is not really an API as much as a set of conventions based around Make and bash, where I need to sit down and read a manual to understand what plugs into where. The same problem exists with MacPorts, which uses Tcl; it's just so much more complicated than it needs to be. The fact that pkgsrc and its ecosystem is is still entirely based on CVS, not just as a sync protocol but as the version control system for everything, is not inspiring, either. I'm sure it works for the people behind this project, but it simply won't lead to me submitting packages. I'm sure I could use pkgsrc simply to install new packages, and treat it like a black box as a "user". But then one day I will need a package that's not in the tree, or I will have to fix a broken package, and I don't want to be left in a situation where I will have to do a lot of work to accomplish something trivial. In 2001 I would have used CVS and I would have hacked packages, not knowing any better. Not in 2012. :-) That said, pkgsrc looks interesting, and I will be keeping an eye on it.

peripetylabs 14y ago

So far, I haven't seen any OS X-specific problems with the build process, everything works fine. The pkgsrc documentation says OS X is officially supported. The pkgsrc-wip project has packages for some of those projects you're looking for: Discount: http://pkgsrc.se/wip/discount http://pkgsrc.se/wip/discount Node: http://pkgsrc.se/wip/node http://pkgsrc.se/wip/node Redis: http://pkgsrc.se/wip/redis http://pkgsrc.se/wip/redis Riak: http://pkgsrc.se/wip/riak http://pkgsrc.se/wip/riak More about pkgsrc-wip: http://pkgsrc-wip.sourceforge.net http://pkgsrc-wip.sourceforge.net To simplify the build process, there is a pkgsrc "front-end" called pkgin: http://pkgin.net http://pkgin.net Hope that helps.

lobster_johnson 14y ago
Thanks, that's helpful. In general the entire system seems rather... antique. It doesn't give me a happy, fuzzy feeling inside. The reason is that I'm not a Unix geek, not in the ways this system wants me to be. Oh, sure, I know the tools; I've written hundreds of bash scripts, I've done my share of C/POSIX programming, I know my way around Make and GCC and so on. But I don't want to do those things. What's so great about Homebrew is that the recipe files are built against an API, which coincidentally is a simple programming language (Ruby). Pkgsrc seems to be based on makefiles, which is not really an API as much as a set of conventions based around Make and bash, where I need to sit down and read a manual to understand what plugs into where. The same problem exists with MacPorts, which uses Tcl; it's just so much more complicated than it needs to be. The fact that pkgsrc and its ecosystem is is still entirely based on CVS, not just as a sync protocol but as the version control system for everything, is not inspiring, either. I'm sure it works for the people behind this project, but it simply won't lead to me submitting packages. I'm sure I could use pkgsrc simply to install new packages, and treat it like a black box as a "user". But then one day I will need a package that's not in the tree, or I will have to fix a broken package, and I don't want to be left in a situation where I will have to do a lot of work to accomplish something trivial. In 2001 I would have used CVS and I would have hacked packages, not knowing any better. Not in 2012. :-) That said, pkgsrc looks interesting, and I will be keeping an eye on it.