Every package must have a unique version number (per epoch)

The RPM package filename must be in the n-v-r (name, version, release) format and must contain the architecture for the package. The proper format is <name>-<version>-<release>.<arch>.rpm. For example, pkgname-1.24-2.i386.rpm is a proper RPM filename.

The n-v-r in the filename must be the same as the n-v-r in the spec file.

If the package is changed in any way, including changing the signature or recompiling, the version or release must be incremented.

The package may obsolete itself.

If a file from the package conflicts with a file from another package in the Fedora Project, the package must use Conflicts: to specify it in the spec file.

The file list for the package must contain all the files in the package so that all files are removed when the package is removed.

The package may not use interactive pre-install, post-install, pre-uninstall, or post-uninstall scripts. The user must not be prompted at anytime during the install, upgrade, or removal — Everything must be completely automated.

The package must not write anything to standard error or standard out. Redirect any messages to /dev/null if they are not necessary, or write them to a log file.

When specifying a group in the spec file, it must be one from /usr/share/doc/rpm-<version>/GROUPS. It there is not an exact match, use the closest match. Do not invent a new group name.

The package can not just unarchive the files in the post-install script. This defeats the purpose of using RPM.

If a file is moved from one binary package to another, the new package with the file must specified the old package in the spec file with the Conflicts: option.

If a newer RPM does not have a binary package that the older SRPMS produced, the binary package not produced anymore must be specified with the Obsoletes: option in the new spec file.