Also consider encap
Also don't forget Encap (http://freshmeat.net/projects/epkg) which I think is the oldest of them. I can't compare them since it's been a while. But for Linux users, the main difference between these and rpm is that you can keep multiple installs of the same package in at once (you do ls -la filename instead of rpm -f filename to find out which package is which). The main disadvantage is, you have to leave old packages installed or possibly break package dependancies (since other packages may have been built against old libraries). This leads to possibly large /usr/local (or whatever mount point it's in).
It would be interesting if these packages could read the SRPM spec files but build into it's directories (of course, most RPMs can't install into any directory) and did the autodependency checking that rpm is good for.
I skimmed 1.9.9. on the website. This is much like the Apache (and database) sections of "Securing & Optimizing Linux" which is available somewhere free on the internet as well as in print from OpenDoc and (a later edition) from OpenNA. The OpenNA version adds information on how to compile MySQL.
Re: Differences between the "secure and optimizing" and the document above. This document as of 1.9.9 covers how to add more modules. The process is a lot simpler than the other one mostly because the other one worries about worthless things such as optimization flags and doing a software audit before and after installation* On the minus side, it doesn't cover things such as how to secure Apache (in particular, no information on a chroot jail), configuring the gory details of the databases. I suppose if you really want to compile Apache yourself, one of these two documents is the best way of figuring it out. But odds are you'll just be writing your own shell scripts to automate the whole mess (believe me) and then you're back to my recommendation at the bottom. If simplicity is your thing, get a Macintosh. MacOSX uses Apache as the personal web server and you can use the recommended tool at the bottom to compile a customized one directly on top of the default. Unlike a company from Redmond which shall remain nameless, Apple can't do anything underhanded like change their licensing or fool around with the registry in an attempt to get you to buy their Server version for a few hundred bucks more.
Some errors. There is some poor grammar at points (English version)--nothing horrible. There isn't an accurate explanation of MM (in either editions BTW).** The author says the distributions don't have Apache, which disagrees with my experience (they're always installed but turned off for security reasons). For the really serious, I believe nowadays RedHat sells a more complete Apache installation separately). It takes about 10 seconds to figure this out for anyone halfway decent. And if you don't feel halfway, get SuSE at the store, if only for the installation manuals (FreeBSD Server it is not, but it's better than nothing for a beginner). Another weakness is the complete lack of anyone pointing out Apachetoolbox (http://www.apachetoolbox.com/). You can do anything but a chroot installation using Apachetoolbox with a swiss army knife of selections that makes both documents pale (if you want a "secure" or super "optimized" installation, you can edit the conf files or ^Z out and do manual patching, etc.). I recommend that anyone ignore both manuals and download Apachetoolbox. When it comes to compiling your own software, there are enough applications out there than to hit your head against a wall with Apache: go to LinuxFromScratch or something...
* "Securing and Optimizing" wastes tons of pages on this in every chapter--a very silly waste of space which wasn't corrected in the later edition: nowadays you'd just use installwatch (something I might add that is Apachetoolbox uses) along with checkinstall (even better than Apachetoolbox's method) to do audit.
** For the record, in plain english. what MM does is allow software in Apache (ModSSL, mod_perl, and mod_php) to create a space that is shared between all the units that server requests. For instance, in PHP, you can easily create IIS-like sessions if MM is compiled and enabled (by default, sessions in PHP use a file system which is slow and abusive, while sessions should be stored on a central DB for enterprises or shared memory for SMEs), there are also programmatic hooks so you can roll your own segment (need to store the number of users who have viewed your website since restart without a database or something similarly trashy?). By far the best use of a shared segment would be in order to do connection pooling like IIS does. Shockingly, most of the PHP database interfaces DON'T DO THIS (So far I think ADODB is the only one). I think mod_python and mod_perl probably do do that.