Wherein I Have Nothing Nice to Say About pkgsrc

I said I'd give pkgsrc a shot and I have. I promised that I'd "do more than install it, stare at the file tree, and then declare it utter crap" and I have.

It's utter crap anyway[1].

Now, that's a pretty incendiary statement to make, so I need to explain myself. I want to do it step by step because one thing that pkgsrc has going for it is that it's very easy to learn to use. Very easy. You can basically get pkgsrc installed in under 5 lines. I do this:

$ wget -nd ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-current/tar_files/pkgsrc.tar.gz
$ gunzip < pkgsrc.tar.gz | (cd /usr; tar -xf -)
$ cd /usr/pkgsrc/bootstrap
$ ./bootstrap --pkgdbdir=/var/db/pkgsrc
$ ln -sf /usr/pkg/bin/bmake /usr/local/bin

Some of this isn't necessary. The bootstrap script is pretty good about working without supervision. The only reason I chose a non-standard db dir is because OpenBSD's ports tree was originally based on NetBSD's pkgsrc, and so there is already a /var/db/pkg dir that I just don't want OpenBSD and pkgsrc sharing.

Easy, right? Right. Let's hope you're not trying to run this on OS X, because pkgsrc thinks the Mac's HFS+ filesystem is garbage. Bootstrapping pkgsrc under Tiger requires creation of a UFS filesystem image that you then install into. In plain English, this means you need to use the included script to create A Very Big File on your Mac that you can then treat like a little virtual hard drive. What this means to you the end user is that if you want to use pkgsrc, you're going to have to live with a disk image mounted in Finder called /Volumes/NetBSD. I can live with that. That's not what makes pkgsrc utter crap. I'm really trying to prove that I gave this thing a shot. Read on.

Now we can begin to immediately install our software. And I do mean immediately.

$ cd /usr/pkgsrc/misc/screen
$ bmake install

Great! screen is a wonderful application! Let's run it already!

$ screen
ksh: screen: not found

What what? But we just installed it! screen, believe it or not, is there, and ready to run...in /usr/pkg/bin.

Points off.

This is pretty minor. You can move screen into /usr/local/bin or you can symlink it. Probably the easiest solution is also my least favorite: put /usr/pkg/bin into your PATH. I don't like this, and for a very good reason. pkgsrc insists on using some of its own unique programs. That's OK! It keeps these programs in /usr/pkg/bin. That's OK! These programs share standard names with other common UNIX programs. That is retarded. Odds are good that your UNIX box already has a tar, cpio, and maybe a pax program. If you put /var/pkg/bin into your path, you aren't going to be sure the next time you type tar if you're going to get your system's own /bin/tar or pkgsrc's /usr/pkg/bin/tar. This can pose a bunch of problems that could easily have been avoided if pkgsrc had just renamed their tools: they changed make to bmake, but they should also have done bdigest, btar, and bcpio.

All right. So pkgsrc has some usability problems. The software gets installed, right? It just gets installed to a place where no one will ever find it. Symlinks save the day, so let's move on.

Hey, I had a big problem getting OpenSSH-4.2 to compile on my iBook last week. pkgsrc to the rescue? Sure, why not?

$ cd /Volumes/NetBSD/pkgsrc/security/openssh
$ bmake install

Whoops! It's downloading OpenSSH-3.9.1! That software package came out on August 17, 2004, making it over a year out of date! Did I fail to update the port? Not possible: The pkgsrc tarball I'm using is 2 days old. I could still install easily this year-old version of OpenSSH from pkgsrc, but why would I want to do so?

More points off.

OK, so OpenSSH was a bust. Let's try a service. Services are nice. I've also been told that installing qmail from pkgsrc is "a no-brainer".

$ cd /usr/pkgsrc/mail/qmail
$ bmake install
$ cd /usr/pkgsrc/mail/qmail-run
$ bmake install

Yep. That was pretty easy. Now how do we get it to run? Already, this has deviated substantially from the lifewithqmail installation method, which works quite well thankyouverymuch. In its defense, the pkgsrc port of qmail mentions lifewithqmail, but it also mentions its own qmail-run package, which demands that I overwrite /etc/mailer.conf and put "qmailsend=YES" and "qmailsmtpd=YES" into /etc/rc.conf. I put them into /etc/rc.conf.local, as per my new rule of not mucking around in /etc/rc.conf. And then I reboot. Guess what? The machine restarts and qmail's not running.

More points off.

Thank God that the qmail-run docs also point you at LWQ and give you a rundown of what it does differently so you can at least reformat your machine and install qmail The Right Way. Otherwise, you're pretty much stuck trying to figure which part of

$ cp /usr/pkg/share/examples/qmail-run/mailer.conf /etc/mailer.conf
$ echo "qmailsend=YES" >> /etc/rc.conf.local
$ echo "qmailsmtpd=YES" >> /etc/rc.conf.local
$ reboot

you got wrong. I had no more luck trying to get dnscache from the djbdns package running, either. This is very bad indeed, since dnscache is absolutely the easiest network service to install on any UNIX box. It makes installing qmail look like a space shuttle mission by comparison. It makes writing a BIND zone file look like brain surgery. I would go so far as to say that it is virtually impossible to mess up a dnscache installation...provided you follow the official installation instructions. I can't fix dnscache because I have no idea what the pkgsrc package is trying to do with the line "dnscache=YES" in /etc/rc.conf. And that's a serious problem: pkgsrc makes troubleshooting a simple dnscache config unnecessarily hard.

More Points off.

I've concluded that it's not the packages themselves that are the problem at this point, but rather some subtle flaw in my pkgsrc installation that neglects to ever look at /etc/rc.conf and /etc/rc.conf.local when deciding what I want to run at boot time. The documentation offers me no help in this regard.

All I can say is that daemontools does not have this problem. You edit /etc/rc.local once and reboot, and from then on out everything you symlink into /service runs, no further rebooting required. It is simply a better way to run your services.

OK, OK. At this point, I'm coming to the realization that maybe DJBware is not the best touchstone for judging pkgsrc. Plenty of distros have problems getting his software to run because it can be so damned persnickety. And sure enough, there isn't a whole lot of other software I want from pkgsrc. If I need audio applications — which I don't — I can get them from OpenBSD's ports tree. And, with the possible exception of XMMS, there isn't anything in pkgsrc that's going to hold a candle to the kind of stuff that OS X comes with. And good luck running X11 apps on OS X. Last time I tried that I had two potential X11 packages to choose from and between them I ended up getting exactly fucking nowhere. What's left? Editors? Don't use 'em. Shells? I roll my own. Security? I already talked about OpenSSH. Time? OpenNTPD. pkgsrc is looking kind of lean all of a sudden. OpenBSD already has a ports tree, and none of the non-DJB software that I want from pkgsrc is up-to-date enough to warrant me using it on my Mac instead of just compiling it from source as necessary.

So yeah. Given this context, pkgsrc is utter crap.

In fact, the one thing I found amidst pkgsrc that I liked was buried deep in sysutils/user_darwin. OpenBSD's ports tree supports rudimentary keyword searching, so you can do a make search key="rsync" to find what you want. pkgsrc has no such counterpart, so you can imagine how deeply I had to dig to find something called "user_darwin". user_darwin is nice because it creates groupadd and useradd scripts that alleviate my need to hack up NetInfo — something I just don't fucking understand whatsoever — when I need to add groups and users to my Mac. So maybe pkgsrc isn't utter crap. It seems to be sufficient for installing some "new basic" tools — things that aren't in the default install yet but should be — things like, bzip2, screen, or mutt. I suggest you avoid pkgsrc like the plague if you want to configure any network service or are interested in learning how UNIX software works in general. It's entirely too hand-wavey, and you're at the mercy of the package maintainer to try to psychically predict what's best in your unique situation. pkgsrc just can't do what I would need it to do in order for it to be useful to me. I found one package I like out of how many thousands of packages available?

You know what? Don't tell me. I don't think the NetBSD folks should brag.



[1] I know one person who is going to read this entire entry as a personal attack, and reviewing it, I can completely understand that it sounds that way. It's not, and I have to apologize for not sugar-coating this any more than I already have. I welcome comments and corrections, positive and negative, about why I shouldn't hate pkgsrc as much as I do, because if this software is as popular as folks say it is, then I have got to be missing something.