When RPM works, it works very well. Ideally, installing an RPM is as simple as downloading one file (the RPM), clicking on it in a GUI browser or executing a simple one-line command to install it, and the package is installed.
If the package needs extra packages installed, tracking down those packages and installing them in the same way can also be done.
RPM's biggest strength is that, when it works, it is actually extremely easy to install/setup a new program. It is also just as trivial to uninstall a program. RPM systems can be even easier to maintain than a Windows system (recall that Windows' Add/Remove? Programs dialog only works if a program registers itself... With RPM, every program is registered and contains detailed information about how to get rid of it.)
Similarily, when RPM works, it supplies a very simple way to update and maintain the programs on your system. Scripts (generally included in distribution CDs) auto-update every RPM on your system. These scripts can work quite well when done correctly. You can take an older Red Hat system (let's say, Red Hat 6.2) and easily upgrade it to the latest one (say, 9.0) using the update CDs. The new system will generally do a very good job of updating your system (though some specific programs may be depreciated and removed, or may get their configurations wiped out... but this is to be expected). It is very rare that an updated RPM-based system ceases to work because of the update.
Another strength is that, from a developer's standpoint, RPM creation is very easy. Making RPMs is by far easier than making packages for other management systems.
RPMs Shortcomings
There are two big problems facing RPM-based systems today.
The first one has to do with the fact that Red Hat and other RPM-based vendors have effectively forked their systems away from eachother to make their RPMs completely incompatible. Thus, whereas several years ago you could take a Mandrake RPM and use it under Red Hat (albeit, with some minor massaging into place), now there is no way. Red Hat even forked the RPM-codebase a couple years back making their RPMs no longer standard (though, I think this has been resolved in recent Red Hat systems).
The second problem is actually the really big one. This problem has an effectionate little term associated with it: Dependency Hell.
Imagine you need to install RPM package "foo". foo has the following dependencies:
bar <= 2.0.14
crunchly <= 1.0.2
smedly <= 0.9.9
So you try to install "bar". Ahh, but bar has the following dependencies:
kringly <= 8.0
bang <= 1.2
So you install "kringly", but it requires:
juniper <= 2.0
killroy <= 1.90
Additionally, all the other packages here have their own set of requirements.
As you can see, very quickly this whole process becomes excruciatingly tedious and difficult. Instead of installing one simple RPM, you are now set to install twenty, thirty, even hundreds of packages. Often times these packages will not even be available for your own distribution, and you will be left with the only options of either a) building your own custom RPM for that packages or b) building the whole thing from source.
Now, this "dependency hell" is really only a problem if you stray from what your distribution supplies for you... However, there are times where you will simply have to stray to satisfy some user need. Imagine if your boss requires you to install an Oracle database, but the only RPMS you can find for your distribution are MySQL? or Postgres. Thus, dependency hell is a very real problem for Linux users and administrators.
