Red Hat NETWORK 4.0 - CHANNEL MANAGEMENTT GUIDE Manual page 13

Chapter 3. Building Custom Packages
3. The RPM package must install without using the
you cannot install an RPM cleanly on your 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. The proper format
is
name-version-release.arch.rpm
filename is
pkgname-0.84-1.i386.rpm
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 (
up2date
mended 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 recom-
piling, the version or release must be increased incrementally. In other words, the
NVRA (including architecture) for each RPM distributed through RHN must corre-
spond 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 depen-
dencies. 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
not necessary. Otherwise, write them to a file.
11. When creating
/usr/share/doc/rpm- < version > /GROUPS
select the next best match.
12. Use the RPM dependency feature to make sure the program runs after it is installed.
Important
Do not create an RPM by archiving files and then unarchiving them in the post-install
script. This defeats the purpose of RPM.
If the files in the archive are not included in the file list, they cannot be verified or examined
for conflicts. In the vast majority of cases, RPM itself can pack and unpack archives most
effectively anyway. For instance, don't create files in a
section.
%postun
) must be forced to accept them. Signing packages is highly recom-
the spec file,
or
--force
. For example, a valid RPM package
, where name is pkgname, version is
/dev/null
use the group
. If there is not an exact match,
that you don't clean up in a
%post
options. If
--nodeps
if they are
definitions from
9