Rhn Rpm Guidelines - Red Hat NETWORK 3.6 - CHANNEL MANAGEMENTT GUIDE Manual

6
Keeping sources pristine may seem important only to developers, but it results in higher quality
software for end users, as well.

3.1.2. RHN RPM Guidelines

The strength of RPM lies in its ability to define dependencies and identify conflicts accurately. Red
Hat Network relies heavily on this aspect of RPM. Red Hat Network offers an automated environ-
ment, which means that no manual intervention can take place during the installation of a package.
Therefore, 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, consult the following resources:
http://www.rpm.org/RPM-HOWTO/
•
http://www.redhat.com/docs/books/max-rpm/
•
http://www.rpm.org/mailing_list/
•
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 be able to be installed without using the
tions. If you cannot install an RPM cleanly on your build system, Red Hat Network will not be
able to install it automatically on a user's system.
4. The RPM package filename must be in the NVR (name, version, release) format and must
contain the architecture for the package. The proper format is name-version-release.arch.rpm.
For example, a valid RPM package filename 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 Red Hat Update Agent (
forced to accept them. Signing packages is recommended and is covered in Section 3.2 Digital
Signatures for RHN 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 ar-
chitecture) for each RPM distributed through RHN must correspond to a unique build to avoid
ambiguities.
7. No RPM package may obsolete itself. This may seem obvious, but it bears mentioning.
8. If an RPM 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 RPM package may rely upon interactive pre-install, post-install, pre-uninstall or
post-uninstall scripts. If the RPM requires direct user intervention during installation, it will
not 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
to a file.
11. When creating the spec file, use the group definitions from
If there is not an exact match, select the next best match.
12. Use the RPM dependency feature to make sure the program will run after it is installed.
Chapter 3. Building Custom Packages
pkgname-0.84-1.i386.rpm
if they are not necessary or write them
/dev/null
/usr/share/doc/rpm-*/GROUPS
or
--force --nodeps
, where name is
) must be
up2date
op-
.