I very strongly advise to NOT ever use a case-sensitive file system. While in this case we have an example of software the <i>NEEDS</i> case sensitivity, a lot of applications folks use will <i>BREAK</i> (or would historically) when installed on a case sensitive file system.<p>Examples include: Dropbox, Steam, Photoshop.
I'm sure more recent versions of these software tools can handle case sensitive file systems (one hopes), but I can say with certainty that there is plenty of other software in the wild, especially if its origins date back using FAT or NTFS on WIN32.<p>In an ideal world, software would be written in a way that works fine on both Case and Case-Insensitive file systems, but we live in a world were software engineering is rarely so disciplined.<p>point being: if you want to use any interesting desktop software that at some point may have been targeted in part at WIN32 systems in some past era, please make sure you stay with a <i>case INsensitive</i> file system<p>that was my PSA for the day/week/month
Has anyone tried this? My two worries are that:<p>(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 <i>work</i>; and<p>(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?<p>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.<p>(Also, I notice NetBSD makes the same mistake as some Linux distros in creating packages for Ruby gems.)<p>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.<p>[1] <a href="http://ftp.netbsd.org/pub/pkgsrc/current/pkgsrc/README-all.html" rel="nofollow">http://ftp.netbsd.org/pub/pkgsrc/current/pkgsrc/README-all.h...</a>
Great article, and it's nice to know there are more choices for package management on the Mac.<p>But, sadly:<p><i>Install Xcode from the Mac App Store...</i><p>This is the main reason why I've stopped using OS X and am installing Linux on the Macs I use personally. I know it's free and I have an Apple ID, but it really bothers me that Xcode is no longer included with the OS and is unavailable as an anonymous download.
> pkgsrc has several advantages over other Mac-specific package managers like MacPorts or Homebrew, especially in regards to security.<p>I'd love to hear a bit more about what those advantages are. Other than portability (which isn't a concern for me, since 99.9% of the non-OS X flavors of Unix I use have apt), the only argument the author gives for pkgsrc over something like Homebrew is that it has "important security features". Furthermore, its setup and use looks a fair bit more complex than Homebrew, making it seem less appealing without having the context the author clearly does.<p>I enjoyed the article, and think it's awesome to know that alternatives to MacPorts/Brew exist, but I'm much more interested in the promised follow-up article about the actual security features of pkgsrc and what makes it worth installing.
On my Mac, I currently install software in at least 8 different ways: pkgsrc, homebrew, GNU stow (for software that is in neither of the first two), gem, pip, drag-and-drop to /Applications, running installers, and using the App Store. It is becoming a bit hard to keep track and keeping things updated, but I've found it really is necessary to use all of these. Frequently a package from pkgsrc will not build, so I'll revert to homebrew. If it's not in homebrew, I have to build it manually or find a binary distribution somewhere.<p>On my Arch Linux system, in constrast, everything is installed using the Package Manager or pip.
Since a lot of the comments here about the case-sensitive file system, note this comment on the blog[1]:<p>> pkgsrc hasn't required a case-sensitive file system for some years now. If you've run across documentation that told you otherwise, could you point me at it so it can be fixed?<p>Assuming that's correct, then using pkgsrc on OSX is very simple: simply download pkgsrc, bootstrap it and then use it.<p>[1]: <a href="http://www.eliteraspberries.com/blog/2013/03/pkgsrc-on-os-x.html#comment-817661833" rel="nofollow">http://www.eliteraspberries.com/blog/2013/03/pkgsrc-on-os-x....</a>
I am not a programmer, and I've used Macs since 1987. As far as I know, I haven't ever used a package manager and don't really know what they are beyond something that lets you install and delete apps.<p>If I want an app, I download it. If I don't want it any more, I move it to the trash. If I really don't want it anymore, I use AppZapper. Can someone explain to me why the issue of package managers comes up so often around these parts and why they're so important to people?
Tried building it, making sure that I used a clean bash environment not polluted with Homebrew or anything else. Bootstrap failed with no particular error, just a useless "exited with status 1".<p>Traced it to bmake/boot-strap, which after building bmake will run "bmake -r -m / test". Apparently bmake doesn't understand the arguments but, in typical Unixy fashion, will not say what it doesn't understand, but will instead output a "usage: bmake ..." and exit with a non-zero exit code, which causes everything to abort.<p>So I added some debug output to bmake's main.c and found that even though boot-strap invoked it with those arguments, bmake itself parsed them as "-j4 -w". Which is what I have MAKEFLAGS set to in my environment. I unset MAKEFLAGS and everything builds.<p>I love Unix, but I just hate how everything exists with so little separation and so much obscure brittleness, ending up in a situation where a tool called "bmake" will use options I intended for GNU Make (which doesn't have a .gnumakerc and so requires a global environment variable).