End-users these days are rarely exposed to "rpm". They'll probably be using yum or PackgeKit (or a GUI-based software installer). RPM, FYI, is the backend package management tool used by Fedora, SuSe, Mandriva, etc (together known as the RPM-based distributions). And it sucks bigtime!
Although RPM has come a long way from what it was in the 1990s and early 2000s, it stands on poor foundations and is unlikely to get any better soon. Having worked on Fedora-ARM for over half a year now, I can see the glaring issues that it faces. Fedora has done a hell of a nice job of mitigating those, but when you start to dig deeper, you realise how filthy the RPM world is.
Here is a link to a VERY old pre-yum days paper, "RPM Hell". Its a google cache link since the site which hosted the original paper was down. Here is the original paper.
Now the interesting thing is that, most of the issues mentioned in this paper STILL EXIST and are very real!
Following issues stand out:
1) Package management is pathetic. If I want to install a terminal-based editor, in all probability, I might end-up installing a whole load of GTK and X crap that I am never going to use. The main reason for this is because RPM packages are monolithic. Large packages like emacs typically install all GUI files needed to support it in X even when it is a headless server. So, we have a (needless) dependency, emacs -> gtk. Now, gtk pulls in LOTS of its own dependencies which are really not required and I end up with a bloated installation. Now, this problem can be solved by splitting emacs into 2 packages. emacs-common and emacs-gtk and I just need to install emacs-common. But, we'll soon realise that there are many capabilities a software can provide and we can't keep making a separate package for each. We'll end up with an unwieldy distribution. So, RPM should have a way of internally defining capabilities and installing only those which are really required.
While we were working on the fedora-ARM project and making a basic rootfs for F-11, we had to build almost half of the GNOME packages to satisfy dependencies. WTH!! Gnome shouldn't even come in the picture yet! But thats what happens when you are working with monolithic packages!
2) There's no way to install multiple versions of a software. Now this is not really a RPM problem, it is an inherent Linux issue. Rules like, all executables go to /usr/bin make it difficult to install multiple versions, since there'll be file conflicts.
So, if "A" needs B-1.0.0 but, "C" needs B-2.0.0, you have to choose between A and C. Fedora has greatly alleviated this problem by making sure every package that requires "B" would require the same version of "B". There are a lot of rebuilds, etc for the purpose. And they are partly justified (If we don't force packages to move to newer versions, they never will and we'll end-up with 10 versions of each package installed on our system). But sometimes, you just need a way around! and there's no way you can do it.
eg. There was a time when we had a working package built aganist python 2.4 and the new distributions had python 2.6. Now there were some difficulties because of which we couldn't rebuild the package aganist python 2.6. Only if there could be multiple versions installed! But sigh! We had to devise some dirty workarounds to get stuff working.
There are many other issues that yum intelligently hides. Most of them are highlighted in the "RPM hell" link above. Guess its time to rethink RPM?