While RPM will run just as well if a package file has been renamed, when the packages are created during RPM's build process, they follow a specific naming convention. The convention is:
A few notes are in order. Normally, the package name is taken verbatim from the packaged software's name. Occasionally, this approach won't work -- usually this occurs when the software is split into multiple ``subpackages,'' each supporting a different set of functions. An example of this situation would be the way ncurses was packaged on Red Hat Linux. The package incorporating ncurses basic functionality was called ncurses, while the package incorporating those parts of ncurses' program development functionality was named ncurses-devel.
The version number is normally taken verbatim from the package's version. The only restriction placed on the version is that it cannot contain a dash ``-''.
The release can be thought of as the package's version. Traditionally it is a number, starting at 1, that shows how many times the packaged software, at a given version, has been built. This is tradition and not a restriction, however. Like the version number, the only restriction is that dashes are not allowed.
The architecture specifier is a string that indicates what hardware the package has been built for. There are a number of architectures defined:
This list will almost certainly change. For the most up-to-date list, please refer to the file /usr/lib/rpmrc. It contains information used internally by RPM, including a list of architectures and equivalent code numbers.