Hi,
[Please pardon the cross posting. I felt that this mail is not off topic for any of the mailing lists I have posted it to, and it is about time we had a technical, as opposed to sentimental or loyalty based look at the .deb and .rpm file formats, I have read the acceptable use policies of all three lists, and I think this is not in violation of any of them. I apologize if I am mistaken]
It might be instructive to compare package file formats on a purely technical level: http://kitenet.net/~joey/pkg-comp/ This is a fairly authoritative document, and well worth understanding.
Here follows commentary on the major points of difference oj just the rpm and deb format (please read the URL for details regarding other package formats).
1) Data unpack-able by standard tools, meta-data accessible by standard tools, and ability to create a .deb with standard (non distribution specific) tools: .debs are just ar archives of tar-balls, and can be unpackaged, inspected, and created using cp, chmod, ar and tar. rpm's need a special tool. Now, why is this important at all? Well, think of a classified environment, where you do not want to rely on the packaged tool to help you with forensics; but you have a trusted solaris box.
2) Package relationships: The .deb format has a more nuanced set of relationships, incorporating recommendations and suggested packages, and orders packages by priority as well as group.
rpm does not have the nuanced relationship, nor priority, but it does have file based dependencies, and easily extract-able copyright information so it is easier to marshal packages by copyright info.
Personally, I am of the opinion that file dependencies are a mixed bag; they complicate the package dependency graph with edges that are different from a package dependency; added to the less nuanced dependency and priority information, they make the installation ordering of rpm's far less sophisticated.
dpkg goes through a song and dance ordering packages with topological sorting of the graph, breaking installation into chunks to ensure that no conflicting packages ever are unpacked at the same time, unpacking and configuring packages in dependency order, and rolling back failed installation. rpm does installations on a best effort basis, and thus failures at critical stages leave the system in an untenable state.
3) rpm can mark documentation files (makes it easier to find docs), and has ghost files, files which are not shipped in the package but are registered as being owned by the package. For documentation, Debian relies on convention; all package documentation is found in /usr/share/doc/$package; but ghost files are clearly a plus for rpms.
4) Debian packages may run binaries at install and un-install times. I am not sure if this is a major plus.
5) Package verification and triggers -- rpm has them, and package verification is one of the major features missing in a .deb. triggers, well, there is a technical proposal currently being debated about adding triggers to dpkg, but obviously, Debian is playing catch-up here.
6) New sections in the package format: .debs were designed to be extensible, and whole new sections can be added to the package by adding yet another tar-ball or the ar archive. Some of the future additions being planned are detached signatures by various keys; developers key, build daemon maintainer key, archive maintainers key, release manager key, mirror master key, -- in a new section of the package file. So, new data sections, compiled binaries for more than one sub-arch, or 32 and 64 bit binaries -- they can be added easily to a new section, and dpkg be told how to deal with the new sections by inspecting the .deb format version.
rpm's can't as easily cope with unseen new requirements.
manoj