The built in (binary) CPack RPM generator (Unix only)
The CPack RPM generator may be used to create RPM packages using CPack. The CPack RPM generator is a CPack generator thus it uses the CPACK_XXX variables used by CPack.
The CPack RPM generator has specific features which are controlled by the specifics CPACK_RPM_XXX variables.
CPACK_RPM_<COMPONENT>_XXXX variables may be used in order to have component specific values. Note however that <COMPONENT> refers to the grouping name written in upper case. It may be either a component name or a component GROUP name. Usually those variables correspond to RPM spec file entities. One may find information about spec files here http://www.rpm.org/wiki/Docs
Note
<COMPONENT> part of variables is preferred to be in upper case (e.g. if component 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 as CPACK_RPM_fOo_XXXX) is still supported for variables defined in older versions of CMake/CPack but is not guaranteed for variables that will be added in the future. For the sake of back compatibility same cased component variables also override upper cased versions where both are present.
Here are some CPack RPM generator wiki resources that are here for historic reasons and are no longer maintained but may still prove useful:
List of CPack RPM generator specific variables:
Enable component packaging for CPack RPM generator
If enabled (ON) multiple packages are generated. By default a single package containing files of all components is generated.
The RPM package summary.
The RPM package name.
Package file name.
Mandatory : YES
replaced by ‘-‘
This may be set to RPM-DEFAULT to allow rpmbuild tool to generate package file 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 for generating debuginfo packages or by simply using multiple components more than one rpm file may be generated, either from a single spec file or from multiple spec files (each component execution produces its own spec file). In such cases duplicate file names may occur as a result of this variable setting or spec file content structure. Duplicate files get overwritten and it is up to the packager to set the variables in a manner that will prevent such errors.
Main component that is packaged without component suffix.
This variable can be set to any component or group name so that component or group rpm package is generated without component suffix in filename and package name.
The RPM package epoch
Optional number that should be incremented when changing versioning schemas or fixing mistakes in the version numbers of older packages.
The RPM package version.
The RPM package architecture.
This may be set to noarch if you know you are building a noarch package.
The RPM package release.
This is the numbering of the RPM package itself, i.e. the version of the packaging and not the version of the content (see CPACK_RPM_PACKAGE_VERSION). One may change the default value if the previous packaging was buggy and/or you want to put here a fancy Linux distro specific numbering.
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.
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 RPM Release: field value is set to ${CPACK_RPM_PACKAGE_RELEASE}%{?dist}.
The RPM package license policy.
The RPM package group.
The RPM package vendor.
The projects URL.
RPM package description.
RPM compression type.
May be used to override RPM compression type to be used to build the RPM. For example some Linux distribution now default to lzma or xz compression whereas older cannot use such RPM. Using this one can enforce compression type to be used.
Possible values are:
RPM spec autoreq field.
May be used to enable (1, yes) or disable (0, no) automatic shared libraries dependency detection. Dependencies are added to requires list.
Note
By default automatic dependency detection is enabled by rpm generator.
RPM spec autoprov field.
May be used to enable (1, yes) or disable (0, no) automatic listing of shared libraries that are provided by the package. Shared libraries are added to provides list.
Note
By default automatic provides detection is enabled by rpm generator.
RPM spec autoreqprov field.
Variable enables/disables autoreq and autoprov at the same time. See CPACK_RPM_PACKAGE_AUTOREQ and CPACK_RPM_PACKAGE_AUTOPROV for more details.
Note
By default automatic detection feature is enabled by rpm.
RPM spec requires field.
May be used to set RPM dependencies (requires). Note that you must enclose the complete requires string between quotes, for example:
set(CPACK_RPM_PACKAGE_REQUIRES "python >= 2.5.0, cmake >= 2.8")
The required package list of an RPM file could be printed with:
rpm -qp --requires file.rpm
RPM spec conflicts field.
May be used to set negative RPM dependencies (conflicts). Note that you must enclose the complete requires string between quotes, for example:
set(CPACK_RPM_PACKAGE_CONFLICTS "libxml2")
The conflicting package list of an RPM file could be printed with:
rpm -qp --conflicts file.rpm
RPM spec requires(pre) field.
May be used to set RPM preinstall dependencies (requires(pre)). Note that you must enclose the complete requires string between quotes, for example:
set(CPACK_RPM_PACKAGE_REQUIRES_PRE "shadow-utils, initscripts")
RPM spec requires(post) field.
May be used to set RPM postinstall dependencies (requires(post)). Note that you must enclose the complete requires string between quotes, for example:
set(CPACK_RPM_PACKAGE_REQUIRES_POST "shadow-utils, initscripts")
RPM spec requires(postun) field.
May be used to set RPM postuninstall dependencies (requires(postun)). Note that you must enclose the complete requires string between quotes, for example:
set(CPACK_RPM_PACKAGE_REQUIRES_POSTUN "shadow-utils, initscripts")
RPM spec requires(preun) field.
May be used to set RPM preuninstall dependencies (requires(preun)). Note that you must enclose the complete requires string between quotes, for example:
set(CPACK_RPM_PACKAGE_REQUIRES_PREUN "shadow-utils, initscripts")
RPM spec suggest field.
May be used to set weak RPM dependencies (suggests). Note that you must enclose the complete requires string between quotes.
RPM spec provides field.
May be used to set RPM dependencies (provides). The provided package list of an RPM file could be printed with:
rpm -qp --provides file.rpm
RPM spec obsoletes field.
May be used to set RPM packages that are obsoleted by this one.
build a relocatable RPM.
If this variable is set to TRUE or ON, the CPack RPM generator will try to build a relocatable RPM package. A relocatable RPM may be installed using:
rpm --prefix or --relocate
in order to install it at an alternate place see rpm(8). Note that currently this may fail if CPACK_SET_DESTDIR is set to ON. If CPACK_SET_DESTDIR is set then you will get a warning message but if there is file installed with absolute path you’ll get unexpected behavior.
Deprecated - use CPACK_RPM_SPEC_MORE_DEFINE instead.
May be used to override the __spec_install_post section within the generated spec file. This affects the install step during package creation, not during package installation. For adding operations to be performed during package installation, use CPACK_RPM_POST_INSTALL_SCRIPT_FILE instead.
RPM extended spec definitions lines.
May be used to add any %define lines to the generated spec file. An example of its use is to prevent stripping of executables (but note that this may also disable other default post install processing):
set(CPACK_RPM_SPEC_MORE_DEFINE "%define __spec_install_post /bin/true")
Toggle CPack RPM generator debug output.
May be set when invoking cpack in order to trace debug information during CPack RPM run. For example you may launch CPack like this:
cpack -D CPACK_RPM_PACKAGE_DEBUG=1 -G RPM
A user provided spec file.
May be set by the user in order to specify a USER binary spec file to be used by the CPack RPM generator instead of generating the file. The specified file will be processed by configure_file( @ONLY).
Spec file template.
If set CPack will generate a template for USER specified binary spec file and stop with an error. For example launch CPack like this:
cpack -D CPACK_RPM_GENERATE_USER_BINARY_SPECFILE_TEMPLATE=1 -G RPM
The user may then use this file in order to hand-craft is own binary spec file which may be used with CPACK_RPM_USER_BINARY_SPECFILE.
Path to file containing pre install/uninstall/transaction script.
May be used to embed a pre installation/uninstallation/transaction script in the spec file. The referred script file (or both) will be read and directly put after the %pre or %preun section If CPACK_RPM_COMPONENT_INSTALL is set to ON the install/uninstall/transaction script for each component can be overridden with CPACK_RPM_<COMPONENT>_PRE_INSTALL_SCRIPT_FILE, CPACK_RPM_<COMPONENT>_PRE_UNINSTALL_SCRIPT_FILE, and CPACK_RPM_<COMPONENT>_PRE_TRANS_SCRIPT_FILE One may verify which scriptlet has been included with:
rpm -qp --scripts package.rpm
Path to file containing post install/uninstall/transaction script.
May be used to embed a post installation/uninstallation/transaction script in the spec file. The referred script file (or both) will be read and directly put after the %post or %postun section. If CPACK_RPM_COMPONENT_INSTALL is set to ON the install/uninstall/transaction script for each component can be overridden with CPACK_RPM_<COMPONENT>_POST_INSTALL_SCRIPT_FILE, CPACK_RPM_<COMPONENT>_POST_UNINSTALL_SCRIPT_FILE, and CPACK_RPM_<COMPONENT>_POST_TRANS_SCRIPT_FILE One may verify which scriptlet has been included with:
rpm -qp --scripts package.rpm
May be used to explicitly specify %(<directive>) file line in the spec file. Like %config(noreplace) or any other directive that be found in the %files section. You can have multiple directives per line, as in %attr(600,root,root) %config(noreplace). Since the CPack RPM generator is generating the list of files (and directories) the user specified files of the CPACK_RPM_<COMPONENT>_USER_FILELIST list will be removed from the generated list. If referring to directories do not add a trailing slash.
RPM changelog file.
May be used to embed a changelog in the spec file. The referred file will be read and directly put after the %changelog section.
list of path to be excluded.
Mandatory : NO
/usr/libx32 /usr/lib64 /usr/share /usr/share/aclocal /usr/share/doc
May be used to exclude path (directories or files) from the auto-generated list of paths discovered by CPack RPM. The default value contains a reasonable set of values if the variable is not defined by the user. If the variable is defined by the user then the CPack RPM generator will NOT any of the default path. If you want to add some path to the default list then you can use CPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST_ADDITION variable.
additional list of path to be excluded.
May be used to add more exclude path (directories or files) from the initial default list of excluded paths. See CPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST.
Packages relocation paths list.
May be used to specify more than one relocation path per relocatable RPM. Variable contains a list of relocation paths that if relative are prefixed by the value of CPACK_RPM_<COMPONENT>_PACKAGE_PREFIX or by the value of CPACK_PACKAGING_INSTALL_PREFIX if the component version is not provided. Variable is not component based as its content can be used to set a different path 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 that component - component must contain at least one file/directory/symbolic link with CPACK_RPM_RELOCATION_PATHS prefix for a certain relocation path to be added. Package will not contain any relocation paths if there are no files/directories/symbolic links on any of the provided prefix locations. Packages that either do not contain any relocation paths or contain files/directories/symbolic links that are outside relocation paths print out an AUTHOR_WARNING that RPM will be partially relocatable.
Per component relocation path install prefix.
May be used to set per component CPACK_PACKAGING_INSTALL_PREFIX for relocatable RPM packages.
Removal of default install prefix from relocation paths list.
Mandatory : NO
are treated as one of relocation paths
May be used to remove CPACK_PACKAGING_INSTALL_PREFIX and CPACK_RPM_<COMPONENT>_PACKAGE_PREFIX from relocatable RPM prefix paths.
May be used to set additional man dirs that could potentially be compressed by brp-compress RPM macro. Variable content must be a list of regular expressions that point to directories containing man files or to man files directly. Note that in order to compress man pages a path must also be present in brp-compress RPM script and that brp-compress script must be added to RPM configuration by the operating system.
Regular expressions that are added by default were taken from brp-compress RPM macro:
default user ownership of RPM content
Value should be user name and not UID. Note that <compName> must be in upper-case.
default group ownership of RPM content
Value should be group name and not GID. Note that <compName> must be in upper-case.
default permissions used for packaged files
Accepted values are lists with PERMISSIONS. Valid permissions are:
Note that <compName> must be in upper-case.
default permissions used for packaged directories
Accepted values are lists with PERMISSIONS. Valid permissions are the same as for CPACK_RPM_DEFAULT_FILE_PERMISSIONS. Note that <compName> must be in upper-case.
force execute permissions on programs and shared libraries
Force set owner, group and world execute permissions on programs and shared libraries. This can be used for creating valid rpm packages on systems such as Debian where shared libraries do not have execute permissions set.
Note
Programs and shared libraries without execute permissions are ignored during separation of debug symbols from the binary for debuginfo packages.
The CPack RPM generator supports packaging of symbolic links:
execute_process(COMMAND ${CMAKE_COMMAND}
-E create_symlink <relative_path_location> <symlink_name>)
install(FILES ${CMAKE_CURRENT_BINARY_DIR}/<symlink_name>
DESTINATION <symlink_location> COMPONENT libraries)
Symbolic links will be optimized (paths will be shortened if possible) before being added to the package or if multiple relocation paths are detected, a post install symlink relocation script will be generated.
Symbolic links may point to locations that are not packaged by the same package (either a different component or even not packaged at all) but those locations will be treated as if they were a part of the package while determining if symlink should be either created or present in a post install script - depending on relocation paths.
Symbolic links that point to locations outside packaging path produce a warning and are treated as non relocatable permanent symbolic links.
Currently there are a few limitations though:
Debuginfo packages contain debug symbols and sources for debugging packaged binaries.
Debuginfo RPM packaging has its own set of variables:
Enable generation of debuginfo RPM package(s).
Note
Binaries must contain debug symbols before packaging so use either Debug or RelWithDebInfo for CMAKE_BUILD_TYPE variable value.
Note
Packages generated from packages without binary files, with binary files but without execute permissions or without debug symbols will cause packaging termination.
Provides locations of root directories of source files from which binaries were built.
Note
For CMake project CPACK_BUILD_SOURCE_DIRS is set by default to point to CMAKE_SOURCE_DIR and CMAKE_BINARY_DIR paths.
Note
Sources with path prefixes that do not fall under any location provided with CPACK_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
for component packaging “/usr/src/debug/<CPACK_PACKAGE_FILE_NAME>-<component>”
Note
Each source path prefix is additionally suffixed by src_<index> where index is index of the path used from CPACK_BUILD_SOURCE_DIRS variable. This produces <CPACK_RPM_BUILD_SOURCE_DIRS_PREFIX>/src_<index> replacement path. Limitation is that replaced path part must be shorter or of equal length than the length of its replacement. If that is not the case either CPACK_RPM_BUILD_SOURCE_DIRS_PREFIX variable has to be set to a shorter path or source directories must be placed on a longer path.
Directories containing sources that should be excluded from debuginfo packages.
Listed paths are owned by other RPM packages and should therefore not be deleted on debuginfo package uninstallation.
Paths that should be appended to CPACK_RPM_DEBUGINFO_EXCLUDE_DIRS for exclusion.
Create a single debuginfo package even if components packaging is set.
When this variable is enabled it produces a single debuginfo package even if component packaging is enabled.
When using this feature in combination with components packaging and there is more than one component this variable requires CPACK_RPM_MAIN_COMPONENT to be set.
Note
If none of the CPACK_RPM_<component>_DEBUGINFO_PACKAGE variables is set then CPACK_RPM_DEBUGINFO_PACKAGE is automatically set to ON when CPACK_RPM_DEBUGINFO_SINGLE_PACKAGE is set.
Debuginfo package file name.
Alternatively provided debuginfo package file name must end with .rpm suffix and should differ from file names of other generated packages.
Variable may contain @cpack_component@ placeholder which will be replaced by component name if component packaging is enabled otherwise it deletes the placeholder.
Setting the variable to RPM-DEFAULT may be used to explicitly set filename generation to default.
Note
CPACK_RPM_FILE_NAME also supports rpmbuild tool generated package file name - disabled by default but can be enabled by setting the variable to RPM-DEFAULT.
SRPM packaging is enabled by setting CPACK_RPM_PACKAGE_SOURCES variable while usually using CPACK_INSTALLED_DIRECTORIES variable to provide directory containing CMakeLists.txt and source files.
For CMake projects SRPM package would be produced by executing:
cpack -G RPM --config ./CPackSourceConfig.cmake
Note
Produced SRPM package is expected to be built with cmake(1) executable and packaged with cpack(1) executable so CMakeLists.txt has to be located in root source directory and must be able to generate binary rpm packages by executing cpack -G command. The two executables as well as rpmbuild must also be present when generating binary rpm packages from the produced SRPM package.
Once the SRPM package is generated it can be used to generate binary packages by creating a directory structure for rpm generation and executing rpmbuild tool:
mkdir -p build_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 sub directories.
Note
SRPM package internally uses CPack/RPM generator to generate binary packages so CMakeScripts.txt can decide during the SRPM to binary rpm generation step what 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 environment variables set by the package manager before starting the process of generating binary rpm packages. This way a single SRPM package can be used to produce different binary rpm packages on different platforms depending on the platform’s packaging rules.
Source RPM packaging has its own set of variables:
Should the content be packaged as a source rpm (default is binary rpm).
Note
For cmake projects CPACK_RPM_PACKAGE_SOURCES variable is set to OFF in CPackConfig.cmake and ON in CPackSourceConfig.cmake generated files.
Additional command-line parameters provided to cmake(1) executable.
Packaging install prefix that would be provided in CPACK_PACKAGING_INSTALL_PREFIX variable for producing binary RPM packages.
List of source rpm build dependencies.
May be used to set source RPM build dependencies (BuildRequires). Note that you must enclose the complete build requirements string between quotes, for example:
set(CPACK_RPM_BUILDREQUIRES "python >= 2.5.0, cmake >= 2.8")