Installation guide

Keeping sources pristine may seem important only to developers, but it results in higher quality
software for end users as well.
4.1.2. Red Hat Network RPM Guidelines
The strength of RPM lies in its ability to define dependencies and identify conflicts accurately. Red Hat
Network relies on this aspect of RPM. Red Hat Network offers an automated environment, which means
that no manual intervention can take place during the installation of a package. T herefore, when building
RPMs for distribution through Red Hat Network, it is imperative to follow these rules:
1. Learn RPM. It is crucial to have a fundamental understanding of the important features of RPM to
build packages properly. For more information about RPM, start with the following resources:
http://docs.fedoraproject.org/en-
US/Fedora_Draft_Documentation/0.1/html/RPM_Guide/index.html
http://docs.fedoraproject.org/en-
US/Fedora_Draft_Documentation/0.1/html/Packagers_Guide/index.html
http://www.gurulabs.com/GURULABS-RPM-LAB/GURULABS-RPM-GUIDE-v1.0.PDF
2. When building an RPM for a child channel, build the package on a fresh install of Red Hat
Enterprise Linux of the same version as the child's base channel. Be sure to apply all updates
from Red Hat Network first.
3. The RPM package must install without using the --force or --nodeps options. If an RPM
cannot be installed cleanly on a build system, Red Hat Network cannot install it automatically on a
system.
4. The RPM package filename must be in the NVR (name, version, release) format and must contain
the architecture for the package. T he proper format is name-version-release.arch.rpm. For
example, a valid RPM package filename is pkgnam e-0.84 -1.i386.rpm , where name is
pkgname, version is 0.84, release is 1, and arch is i386.
5. The RPM package should be signed by the maintainer of the package. Unsigned packages may
be distributed through Red Hat Network, but the yum updater must be forced to accept them.
Signing packages is highly recommended and is covered in Section 4.2, “Digital Signatures for
Red Hat Network Packages”.
6. If the package is changed in any way, including changing the signature or recompiling, the version
or release must be increased incrementally. In other words, the NVRA (including architecture) for
each RPM distributed through Red Hat Network must correspond to a unique build to avoid
ambiguities.
7. No RPM package may obsolete itself.
8. If a package is split into separate packages, be extremely careful with the dependencies. Do not
split an existing package unless there is a compelling reason to do so.
9. No package may rely upon interactive pre-install, post-install, pre-uninstall, or post-uninstall
scripts. If the package requires direct user intervention during installation, it cannot work with Red
Hat Network.
10. Any pre-install, post-install, pre-uninstall, and post-uninstall scripts should never write anything to
stderr or stdout. Redirect the messages to /dev/null if they are not necessary. Otherwise, write
them to a file.
11. When creating the spec file, use the group definitions from
/usr/share/doc/rpm-<version>/GROUPS. If there is not an exact match, select the next best
match.
12. Use the RPM dependency feature to make sure the program runs after it is installed.
Red Hat Satellite 5.6 Reference Guide
60