Additional RPM features (applies to other packagers, too)
All too often, RPM packages appear to rely on a particular package name as a dependency. This is fine if you are only using packages from one package vendor, but once you start to mix them, things can get ugly. The purpose of packages is to bundle up related components (docs, binaries, libs) into one file for easy distribution and installation. If you install a RedHat RPM of Mesa and you install a SuSE RPM of a program that needs Mesa to work, I have seen the combination of differing packagers fail.
Here is what I propose. Instead of each package listing other package names as dependencies, have an association between each package that is installed on a system and the capability or capabilities that it provides. This sort of association is potentially cross-distribution. We could set up some sort of central repository of what capabilities (from a joint-proposed name) exist on a system and what package provides it as a DBM-style database file. Each packager (deb, rpm, etc...) will be responsible for updating this database with its capabilities and reading it for capability conflicts.
This will work towards elimination of that all-annoying rpm --force -Uvh .i386.rpm by removing the dependence on a particular package naming scheme and replacing it with a joint-approved capability based setup. Tools could also exist to allow people to register the capability of software that they installed that didn't use a package managing system (.tar, for example). That way, if someone wanted to download and install Mesa by .tar and then install a package that required libGL.so, they could register that the Mesa.tar.gz provided the OpenGL execution capability, version 1.1. Then, when they went to install GLQuake.i386.rpm, the package manager would check it dependent capabilities and then happily install or alert the user if capabilities were missing. In either case, the user wouldn't have to rpm --force -Uvh each package that wanted the OpenGL execution capability, version 1.1.
Comments on this are solicited to firstname.lastname@example.org (mailto:email@example.com).