RPM (RedHat Package Manager) is a package management system for RHEL based systems. You may have seen that all the packages in Redhat based systems have extension.rpm.This tutorial will help you to how to create RPM for your own script.

The built in (binary) CPack RPM generator (Unix only)

Variables specific to CPack RPM generator¶

CPackRPM may be used to create RPM packages using CPack.CPackRPM is a CPack generator thus it uses the CPACK_XXXvariables used by CPack.

CPackRPM has specific features which are controlled by the specificsCPACK_RPM_XXX variables.

CPACK_RPM_<COMPONENT>_XXXX variables may be used in order to havecomponent specific values. Note however that <COMPONENT> refers to thegrouping name written in upper case. It may be either a component name ora component GROUP name. Usually those variables correspond to RPM spec fileentities. One may find information about spec files herehttp://www.rpm.org/wiki/Docs

Note

<COMPONENT> part of variables is preferred to be in upper case (for e.g. ifcomponent is named foo then use CPACK_RPM_FOO_XXXX variable name format)as is with other CPACK_<COMPONENT>_XXXX variables.For the purposes of back compatibility (CMake/CPack version 3.5 and lower)support for same cased component (e.g. fOo would be used asCPACK_RPM_fOo_XXXX) is still supported for variables defined in olderversions of CMake/CPack but is not guaranteed for variables thatwill be added in the future. For the sake of back compatibility same casedcomponent variables also override upper cased versions where both arepresent.

Here are some CPackRPM wiki resources that are here for historic reasons andare no longer maintained but may still prove useful:

List of CPackRPM specific variables:

Enable component packaging for CPackRPM

• Mandatory : NO
• Default : OFF

If enabled (ON) multiple packages are generated. By default a single packagecontaining files of all components is generated.

The RPM package summary.

• Mandatory : YES
• Default : CPACK_PACKAGE_DESCRIPTION_SUMMARY

The RPM package name.

• Mandatory : YES
• Default : CPACK_PACKAGE_NAME

Package file name.

• Mandatory : YES

• Default :<CPACK_PACKAGE_FILE_NAME>[-<component>].rpm with spaces

  replaced by ‘-‘

This may be set to RPM-DEFAULT to allow rpmbuild tool to generate packagefile name by itself.Alternatively provided package file name must end with .rpm suffix.

Note

By using user provided spec file, rpm macro extensions such as forgenerating debuginfo packages or by simply using multiple components morethan one rpm file may be generated, either from a single spec file or frommultiple spec files (each component execution produces it’s own spec file).In such cases duplicate file names may occur as a result of this variablesetting or spec file content structure. Duplicate files get overwrittenand it is up to the packager to set the variables in a manner that willprevent such errors.

The RPM package version.

• Mandatory : YES
• Default : CPACK_PACKAGE_VERSION

The RPM package architecture.

• Mandatory : YES
• Default : Native architecture output by uname-m

This may be set to noarch if you know you are building a noarch package.

The RPM package release.

• Mandatory : YES
• Default : 1

This is the numbering of the RPM package itself, i.e. the version of thepackaging and not the version of the content (seeCPACK_RPM_PACKAGE_VERSION). One may change the default value ifthe previous packaging was buggy and/or you want to put here a fancy Linuxdistro specific numbering. Winner game todd review.

Note

This is the string that goes into the RPM Release: field. Some distros(e.g. Fedora, CentOS) require 1%{?dist} format and not just a number.%{?dist} part can be added by setting CPACK_RPM_PACKAGE_RELEASE_DIST.

The dist tag that is added RPM Release: field.

• Mandatory : NO
• Default : OFF

This is the reported %{dist} tag from the current distribution or empty%{dist} if RPM macro is not set. If this variable is set then RPMRelease: field value is set to ${CPACK_RPM_PACKAGE_RELEASE}%{?dist}.

The RPM package license policy.

• Mandatory : YES
• Default : “unknown”

The RPM package group.

• Mandatory : YES
• Default : “unknown”

The RPM package vendor.

• Mandatory : YES
• Default : CPACK_PACKAGE_VENDOR if set or “unknown”

The projects URL.

• Mandatory : NO
• Default : -

RPM package description.

• Mandatory : YES
• Default : _DESCRIPTION'>CPACK_COMPONENT_<compName>_DESCRIPTION (componentbased installers only) if set, CPACK_PACKAGE_DESCRIPTION_FILEif set or “no package description available”

RPM compression type.

• Mandatory : NO
• Default : -

May be used to override RPM compression type to be used to build theRPM. For example some Linux distribution now default to lzma or xzcompression whereas older cannot use such RPM. Using this one can enforcecompression type to be used.

Possible values are:

• lzma
• xz
• bzip2
• gzip

RPM spec autoreq field.

• Mandatory : NO
• Default : -

May be used to enable (1, yes) or disable (0, no) automatic shared librariesdependency detection. Dependencies are added to requires list.

Note

By default automatic dependency detection is enabled by rpm generator.

RPM spec autoprov field.

• Mandatory : NO
• Default : -

May be used to enable (1, yes) or disable (0, no) automatic listing of sharedlibraries that are provided by the package. Shared libraries are added toprovides list.

Note

By default automatic provides detection is enabled by rpm generator.

RPM spec autoreqprov field.

• Mandatory : NO
• Default : -

Variable enables/disables autoreq and autoprov at the same time.See CPACK_RPM_PACKAGE_AUTOREQ and CPACK_RPM_PACKAGE_AUTOPROVfor more details.

Note

By default automatic detection feature is enabled by rpm.

RPM spec requires field.

• Mandatory : NO
• Default : -

May be used to set RPM dependencies (requires). Note that you must enclosethe complete requires string between quotes, for example:

The required package list of an RPM file could be printed with:

RPM spec conflicts field.

• Mandatory : NO
• Default : -

May be used to set negative RPM dependencies (conflicts). Note that you mustenclose the complete requires string between quotes, for example:

The conflicting package list of an RPM file could be printed with:

RPM spec requires(pre) field.

• Mandatory : NO
• Default : -

May be used to set RPM preinstall dependencies (requires(pre)). Note thatyou must enclose the complete requires string between quotes, for example:

RPM spec requires(post) field.

• Mandatory : NO
• Default : -

May be used to set RPM postinstall dependencies (requires(post)). Note thatyou must enclose the complete requires string between quotes, for example:

RPM spec requires(postun) field.

• Mandatory : NO
• Default : -

May be used to set RPM postuninstall dependencies (requires(postun)). Notethat you must enclose the complete requires string between quotes, forexample:

RPM spec requires(preun) field.

• Mandatory : NO
• Default : -

May be used to set RPM preuninstall dependencies (requires(preun)). Note thatyou must enclose the complete requires string between quotes, for example:

RPM spec suggest field.

• Mandatory : NO
• Default : -

May be used to set weak RPM dependencies (suggests). Note that you mustenclose the complete requires string between quotes.

RPM spec provides field.

• Mandatory : NO
• Default : -

May be used to set RPM dependencies (provides). The provided package listof an RPM file could be printed with:

RPM spec obsoletes field.

• Mandatory : NO
• Default : -

May be used to set RPM packages that are obsoleted by this one.

build a relocatable RPM.

• Mandatory : NO
• Default : CPACK_PACKAGE_RELOCATABLE

If this variable is set to TRUE or ON CPackRPM will tryto build a relocatable RPM package. A relocatable RPM maybe installed using:

in order to install it at an alternate place see rpm(8). Note thatcurrently this may fail if CPACK_SET_DESTDIR is set to ON. IfCPACK_SET_DESTDIR is set then you will get a warning message butif there is file installed with absolute path you’ll get unexpected behavior.

Deprecated - use CPACK_RPM_POST_INSTALL_SCRIPT_FILE instead.

• Mandatory : NO
• Default : -
• Deprecated: YES

This way of specifying post-install script is deprecated, useCPACK_RPM_POST_INSTALL_SCRIPT_FILE.May be used to set an RPM post-install command inside the spec file.For example setting it to /bin/true may be used to preventrpmbuild to strip binaries.

RPM extended spec definitions lines.

• Mandatory : NO
• Default : -

May be used to add any %define lines to the generated spec file.

Toggle CPackRPM debug output.

• Mandatory : NO
• Default : -

May be set when invoking cpack in order to trace debug informationduring CPack RPM run. For example you may launch CPack like this:

A user provided spec file.

• Mandatory : NO
• Default : -

May be set by the user in order to specify a USER binary spec fileto be used by CPackRPM instead of generating the file.The specified file will be processed by configure_file( @ONLY).

Spec file template.

• Mandatory : NO
• Default : -

If set CPack will generate a template for USER specified binaryspec file and stop with an error. For example launch CPack like this:

The user may then use this file in order to hand-craft is ownbinary spec file which may be used withCPACK_RPM_USER_BINARY_SPECFILE.

Path to file containing pre (un)install script.

• Mandatory : NO
• Default : -

May be used to embed a pre (un)installation script in the spec file.The referred script file (or both) will be read and directlyput after the %pre or %preun sectionIf CPACK_RPM_COMPONENT_INSTALL is set to ON the (un)installscript for each component can be overridden withCPACK_RPM_<COMPONENT>_PRE_INSTALL_SCRIPT_FILE andCPACK_RPM_<COMPONENT>_PRE_UNINSTALL_SCRIPT_FILE.One may verify which scriptlet has been included with:

Path to file containing post (un)install script.

• Mandatory : NO
• Default : -

May be used to embed a post (un)installation script in the spec file.The referred script file (or both) will be read and directlyput after the %post or %postun section.If CPACK_RPM_COMPONENT_INSTALL is set to ON the (un)installscript for each component can be overridden withCPACK_RPM_<COMPONENT>_POST_INSTALL_SCRIPT_FILE andCPACK_RPM_<COMPONENT>_POST_UNINSTALL_SCRIPT_FILE.One may verify which scriptlet has been included with:

• Mandatory : NO
• Default : -

May be used to explicitly specify %(<directive>) file linein the spec file. Like %config(noreplace) or any other directivethat be found in the %files section. Since CPackRPM is generatingthe list of files (and directories) the user specified files ofthe CPACK_RPM_<COMPONENT>_USER_FILELIST list will be removed fromthe generated list.

RPM changelog file.

• Mandatory : NO
• Default : -

May be used to embed a changelog in the spec file.The referred file will be read and directly put after the %changelogsection.

list of path to be excluded.

• Mandatory : NO
• Default : /etc /etc/init.d /usr /usr/share /usr/share/doc /usr/bin /usr/lib /usr/lib64 /usr/include

May be used to exclude path (directories or files) from the auto-generatedlist of paths discovered by CPack RPM. The defaut value contains areasonable set of values if the variable is not defined by the user. If thevariable is defined by the user then CPackRPM will NOT any of the defaultpath. If you want to add some path to the default list then you can useCPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST_ADDITION variable.

additional list of path to be excluded.

• Mandatory : NO
• Default : -

May be used to add more exclude path (directories or files) from the initialdefault list of excluded paths. SeeCPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST.

Packages relocation paths list.

• Mandatory : NO
• Default : -

May be used to specify more than one relocation path per relocatable RPM.Variable contains a list of relocation paths that if relative are prefixedby the value of _PACKAGE_PREFIX'>CPACK_RPM_<COMPONENT>_PACKAGE_PREFIX or by thevalue of CPACK_PACKAGING_INSTALL_PREFIX if the component versionis not provided.Variable is not component based as its content can be used to set a differentpath prefix for e.g. binary dir and documentation dir at the same time.Only prefixes that are required by a certain component are added to thatcomponent - component must contain at least one file/directory/symbolic linkwith CPACK_RPM_RELOCATION_PATHS prefix for a certain relocationpath to be added. Package will not contain any relocation paths if there areno files/directories/symbolic links on any of the provided prefix locations.Packages that either do not contain any relocation paths or containfiles/directories/symbolic links that are outside relocation paths printout an AUTHOR_WARNING that RPM will be partially relocatable.

Per component relocation path install prefix.

• Mandatory : NO
• Default : CPACK_PACKAGING_INSTALL_PREFIX

May be used to set per component CPACK_PACKAGING_INSTALL_PREFIXfor relocatable RPM packages.

Removal of default install prefix from relocation paths list.

• Mandatory : NO

• Default :CPACK_PACKAGING_INSTALL_PREFIX or CPACK_RPM_<COMPONENT>_PACKAGE_PREFIX

  are treated as one of relocation paths

May be used to remove CPACK_PACKAGING_INSTALL_PREFIX and CPACK_RPM_<COMPONENT>_PACKAGE_PREFIXfrom relocatable RPM prefix paths.

• Mandatory : NO
• Default : -

May be used to set additional man dirs that could potentially be compressedby brp-compress RPM macro. Variable content must be a list of regularexpressions that point to directories containing man files or to man filesdirectly. Note that in order to compress man pages a path must also bepresent in brp-compress RPM script and that brp-compress script must beadded to RPM configuration by the operating system.

Regular expressions that are added by default were taken from brp-compressRPM macro:

• /usr/man/man.*
• /usr/man/.*/man.*
• /usr/info.*
• /usr/share/man/man.*
• /usr/share/man/.*/man.*
• /usr/share/info.*
• /usr/kerberos/man.*
• /usr/X11R6/man/man.*
• /usr/lib/perl5/man/man.*
• /usr/share/doc/.*/man/man.*
• /usr/lib/.*/man/man.*

default user ownership of RPM content

• Mandatory : NO
• Default : root

Value should be user name and not UID.Note that <compName> must be in upper-case.

default group ownership of RPM content

• Mandatory : NO
• Default : root

Value should be group name and not GID.Note that <compName> must be in upper-case.

default permissions used for packaged files

• Mandatory : NO
• Default : - (system default)

Accepted values are lists with PERMISSIONS. Valid permissionsare:

• OWNER_READ
• OWNER_WRITE
• OWNER_EXECUTE
• GROUP_READ
• GROUP_WRITE
• GROUP_EXECUTE
• WORLD_READ
• WORLD_WRITE
• WORLD_EXECUTE

Note that <compName> must be in upper-case.

default permissions used for packaged directories

• Mandatory : NO
• Default : - (system default)

Accepted values are lists with PERMISSIONS. Valid permissionsare the same as for CPACK_RPM_DEFAULT_FILE_PERMISSIONS.Note that <compName> must be in upper-case.

Packaging of Symbolic Links¶

CPackRPM supports packaging of symbolic links:

Symbolic links will be optimized (paths will be shortened if possible)before being added to the package or if multiple relocation paths aredetected, a post install symlink relocation script will be generated.

Symbolic links may point to locations that are not packaged by the samepackage (either a different component or even not packaged at all) butthose locations will be treated as if they were a part of the packagewhile determining if symlink should be either created or present in apost install script - depending on relocation paths.

Symbolic links that point to locations outside packaging path produce awarning and are treated as non relocatable permanent symbolic links.

Currently there are a few limitations though:

• For component based packaging component interdependency is not checkedwhen processing symbolic links. Symbolic links pointing to content ofa different component are treated the same way as if pointing to locationthat will not be packaged.
• Symbolic links pointing to a location through one or more intermediatesymbolic links will not be handled differently - if the intermediatesymbolic link(s) is also on a relocatable path, relocating it duringpackage installation may cause initial symbolic link to point to aninvalid location.

Packaging of debug information¶

Debuginfo packages contain debug symbols and sources for debugging packagedbinaries.

Note

Currently multiple debuginfo packages are generated if component basedpackaging is used - one debuginfo package per component. This duplicatessources if multiple binaries are using them. This is a side effect ofhow CPackRPM currently generates component packages and will be addressedin later versions of the generator.

Debuginfo RPM packaging has it’s own set of variables:

Enable generation of debuginfo RPM package(s).

• Mandatory : NO
• Default : OFF

Note

Binaries must contain debug symbols before packaging so use either Debugor RelWithDebInfo for CMAKE_BUILD_TYPE variable value.

Note

Packages generated from packages without binary files, with binary files butwithout execute permissions or without debug symbols will be empty.

Provides locations of root directories of source files from which binarieswere built.

• Mandatory : YES if CPACK_RPM_DEBUGINFO_PACKAGE is set
• Default : -

Note

For CMake project CPACK_BUILD_SOURCE_DIRS is set by default topoint to CMAKE_SOURCE_DIR and CMAKE_BINARY_DIR paths.

Note

Sources with path prefixes that do not fall under any location provided withCPACK_BUILD_SOURCE_DIRS will not be present in debuginfo package.

Prefix of location where sources will be placed during package installation.

• Mandatory : YES if CPACK_RPM_DEBUGINFO_PACKAGE is set

• Default :“/usr/src/debug/<CPACK_PACKAGE_FILE_NAME>” and

  for component packaging “/usr/src/debug/<CPACK_PACKAGE_FILE_NAME>-<component>”

Note

Each source path prefix is additionaly suffixed by src_<index> whereindex is index of the path used from CPACK_BUILD_SOURCE_DIRSvariable. This produces <CPACK_RPM_BUILD_SOURCE_DIRS_PREFIX>/src_<index>replacement path.Limitation is that replaced path part must be shorter or of equallength than the length of its replacement. If that is not the case eitherCPACK_RPM_BUILD_SOURCE_DIRS_PREFIX variable has to be set toa shorter path or source directories must be placed on a longer path.

Directories containing sources that should be excluded from debuginfo packages.

• Mandatory : NO
• Default : “/usr /usr/src /usr/src/debug”

Listed paths are owned by other RPM packages and should therefore not bedeleted on debuginfo package uninstallation.

Paths that should be appended to CPACK_RPM_DEBUGINFO_EXCLUDE_DIRSfor exclusion.

• Mandatory : NO
• Default : -

Packaging of sources (SRPM)¶

SRPM packaging is enabled by setting CPACK_RPM_PACKAGE_SOURCESvariable while usually using CPACK_INSTALLED_DIRECTORIES variableto provide directory containing CMakeLists.txt and source files.

For CMake projects SRPM package would be product by executing:

cpack-GRPM--config./CPackSourceConfig.cmake

Note

Produced SRPM package is expected to be built with cmake(1) executableand packaged with cpack(1) executable so CMakeLists.txt has to belocated in root source directory and must be able to generate binary rpmpackages by executing cpack-G command. The two executables as well asrpmbuild must also be present when generating binary rpm packages from theproduced SRPM package.

Once the SRPM package is generated it can be used to generate binary packagesby creating a directory structure for rpm generation and executing rpmbuildtool:

mkdir-pbuild_dir/{BUILD,BUILDROOT,RPMS,SOURCES,SPECS,SRPMS}rpmbuild--define'_topdir<path_to_build_dir>'--rebuild<SRPM_file_name>

Generated packages will be located in build_dir/RPMS directory or its subdirectories.

Note

SRPM package internally uses CPack/RPM generator to generate binary packagesso CMakeScripts.txt can decide during the SRPM to binary rpm generation stepwhat content the package(s) should have as well as how they should be packaged(monolithic or components). CMake can decide this for e.g. by reading environmentvariables set by the package manager before starting the process of generatingbinary rpm packages. This way a single SRPM package can be used to producedifferent binary rpm packages on different platforms depending on the platform’spackaging rules.

Source RPM packaging has it’s own set of variables:

Should the content be packaged as a source rpm (default is binary rpm).

• Mandatory : NO
• Default : OFF

Note

For cmake projects CPACK_RPM_PACKAGE_SOURCES variable is setto OFF in CPackConfig.cmake and ON in CPackSourceConfig.cmakegenerated files.

Additional command-line parameters provided to cmake(1) executable.

• Mandatory : NO
• Default : -

Packaging install prefix that would be provided in CPACK_PACKAGING_INSTALL_PREFIXvariable for producing binary RPM packages.

• Mandatory : YES
• Default : “/”

Home > Articles > Operating Systems, Server

1. The Spec File

The Spec File

When you build packages, you use spec files to provide the information and scripts that automate the package-building process itself, and the information and scripts that are bundled as part of the package. This second set of scripts is used on the user's system when the package is installed.

These two sets of information are intermingled in the spec file, without any distinction between them other than their names. However, it is important to remember which items are used on your system during the package-building process and which items are used on the end user's system during package use.

The spec file for a package is located in the SPECS directory and needs to have a filename consisting of the name of the package, the version number, and the extension .spec. For example, the name of the spec file for ed is ed-0.2.spec. For spec files that are used to produce multiple packages (such as –devel or –static packages), the base package name is used for the filename.

A spec file includes two different kinds of entries: one-line fields and multiline sections. The one-line fields are placed at the top of the file in the header, and the sections follow. Most sections in the spec file contain Bourne shell scripts that run either during the package-building process or on the end user's system during package installation or removal. However, the %Description section is just a series of text lines that describe the package. Listing 1 shows the spec file for the ed package on Caldera OpenLinux, which is used for the examples in this chapter. This spec file has been simplified to shorten it for inclusion in this article. If you have installed the ed source RPM, you can look at the unedited version at /usr/src/distribution/SPECS/ed-0.2.spec.

Listing 1 The Spec File for ed (Simplified)

Fields in the Spec File

Fields are indicated with the field name followed by a colon. A pound sign (#) indicates a comment in the spec file, either in the header or in any of the sections.

Most of the fields are pieces of information that are just put into the package when it is built. However, some are used during the actual build process.

Informational Fields

The following are descriptions of the informational fields most commonly used in a spec file:

• Summary—A one-line description of the package.

• Name—The name of the package.

• Version—The version of the software in the package.

• Release—The release number of the package. This is what you modify if you make changes to the package (that is, when the original version of the software has not changed).

• Group—The group is a multipart (usually two-part) string used by package-management utilities to organize the packages into a hierarchy. The parts of the group are separated by a slash. For example, the ed package is in the Textprocessing/Editor group. A list of all the groups is available in the GROUPS file with your RPM documentation (usually /usr/doc/rpm-3.0.5, if you have it installed.)

• Copyright—This indicates the copyright holder and the license that the software uses. Common values for the license are BSD, distributable, GPL, artistic, public domain, MIT, freeware, and shareware.

• Packager—This provides the name and email address of the person who built this package. In the case of packages that come with your distribution, this field is often used to track who internally maintains the package. Please don't contact this person to get support for the software in the package. If you have questions about the software provided by a package, visit the site at which the software originated, or use other normal support channels.

• Provides—This lists the items that the package provides. The package automatically provides its own name and all the files that it contains (including shared libraries and interpreters), so these do not need to be explicitly listed.

• Requires—This lists the items that the package requires. If programs in the package require shared libraries or interpreters, rpm detects this automatically, and these items do not need to be explicitly listed.

• Conflicts—This lists conflicts that the package has. For instance, if this were a mail engine, it might conflict with sendmail because there can usually be only one mail engine on a machine. This information is used by RPM to prevent two conflicting packages from being installed on the same machine.

• Obsoletes—This lists packages that are obsoleted by this package. This is a more specific version of the Conflicts field.

• BuildRoot—This option instructs RPM to place files in a temporary directory during the install step. This is very useful when building packages for a distribution. For more information, see the section 'BuildRoot,' later in this article.

• %Description—This is a multiline description of the package. Actually, this is a section and not a field, but it fits better here because it is purely informational and is not used during package building.

Fields Used During Package Building

The following fields are used during the build process:

• Icon—This is the graphics file (often GIF) that contains an icon for this package (used by graphical package-management tools).

• Source#—This is a URL for the source files for the software. The filename part is used by the build process, and the rest of the URL is for informational purposes. Note that Source is the same as Source0 (the 0 is optional).

• Patch#—These entries denote the filenames of the patch files used during the build process. Patch is the same as Patch0.

Sections

Sections in the spec file begin with a section identifier and continue until the next section identifier. The section identifiers start with a percent sign.

Unfortunately, rpm uses a percent sign to indicate both section identifiers and directives in the %Prep and %Files sections, which can be confusing. Some packagers capitalize the first letter of section identifiers and leave directive names in all lowercase to distinguish the two in their spec files, but this is not universal.

Most sections in the spec file contain shell scripts that perform the actions required for that stage of the build process.

Sections Used During the Build Process

The following sections are used during the build process:

• %Prep—This section contains a shell script to extract the source files and apply the patches. It is used during the prep stage.

• %Build—This contains a shell script to build (compile) the software. It is used during the build stage.

• %Install—This contains a shell script to install the software. This is used during the install stage. (You can probably see a pattern emerging here!)

• %Files—This section contains a listing of the files and directories in the package.

• %Clean—This optional section contains a shell script to clean up after a package build.

• %Changelog—This contains changelog information about the SPEC file itself.

Sections for Package Scripts

The following scripts are not used at build time; they are inserted into the package and are used by the package manager on the end user's system when the package is installed, removed, or verified.

• %Pre/%Post—Scripts to run on the end user's system before and after installing the package files.

• %Preun/%Postun—Scripts to run on the end user's system before and after removing the package files.

• %Triggerin/%Triggerun—Scripts to run when a specific package is installed and uninstalled. For example, these could be used by a mail client to add sendmail support whenever sendmail is installed.

• %Triggerpostun—Script to run after a specific package is uninstalled (versus before the package is uninstalled, in the case of %Triggerun).

• %Verify—Script to run on the end user's system to verify the package files. If empty, the default verification mechanism of RPM is used.

Helper Packages

It is common to have helper packages defined in a spec file. For example, if the package mypackage also has a mypackage-devel package, both will be described in the same spec file. Generally, the only thing that differs in the helper packages is the list of files and the information fields. To define the information fields for a helper package, the spec file uses the %package directive followed by the fields. After that, sections use the package's name to differentiate—for example:

Related Resources

• Book $27.99

• Book $39.99

• Book $31.99