I dunno what people mean when they talk about RPM hell

When people talk about RPM dependency hell, I really have no idea what they're talking about. Here's a factual look into RPM that should set the record straight:

Warning ahead: please note that I'm not gonna discuss Debian vs. Red Hat, but dpkg vs. RPM.

RPM, combined with a good package manager such as Smart, is vastly superior to the competition:

The strengths of RPM

• No indirections -- 100% of the times, the manifest corresponds to the installed files. Have you seen dpkg detours/indirections (dunno their name in English)?
• Built-in integrity checking. rpm -V. Can't get any easier than that.
• The dependency system is cleaner. It allows and actually by default generates dependencies on files, which rocks when several packages provide the same functionality.
• The RPM philosophy doesn't allow interruptions during package installation or removal. No stupid questions about config files getting replaced or not, license agreements and configuration questions. This guarantees unattended transactional installations/upgrades (dpkg does not guarantee it without extra effort, because it defaults to interactive behavior) whereas with dpkg, if you answer one question wrong, your system may stay unconfigured. I know it because I lived it. I'd very much rather have the package come in a default useful configuration then configure it than have an assistant interrupt me upon installation to ask me how I want to configure it.
• RPM supports two versions of a package with the same name, whereas dpkg does not. I know this because I have a machine with kdelibs 3.5.7 and kdelibs 1.4 to support Katalog from KDE 1.0, and no broken dependencies. However, this is regrettably a theoretical advantage because as of late many RPM-based distros have picked up the bad habit of naming stuff after Debian package conventions (think libXXX2.2); the Debian practice is both unneeded in the RPM world and stupid because the version of the package does not conceptually belong in the package name, and doing that constitutes a hacky workaround around inferior technology which RPM does not need.

The disadvantages

The only things RPM has going against it? It's a bit harder to prepare spec files for RPMs, and it's hard to prepare distro-agnostic RPMs, which has the logical consequence of reducing availability of RPMs ready to install. RPM-based distros should take a clue from deb-based ones right now, or else they risk continuing to get kicked in the ass for the foreseeable future.

Discuss.