Packaging and distributing software

Natively compiled software is software written in a programming language that compiles to machine code with a resulting binary executable file. Natively compiled software is standalone software.

Some programming languages, such as Bash or Python, do not compile to machine code. Instead, a language interpreter or a language virtual machine executes the programs' source code step-by-step without prior transformations.

You can either raw-interpret or byte-compile software written in interpreted languages:

Note that the way you build and package software by using RPM is different for these two software types.

You can build software written in a compiled language into an executable by using one of the following methods:

#include <stdio.h>

int main(void) {
    printf("Hello World\n");
    return 0;
}

You can convert the source code written in an interpreted programming language into machine code by using one of the following methods:

print("Hello World")

#!/bin/bash

printf "Hello World\n"

You can create a patch from the original source code by using the diff utility. For example, to patch a Hello world program written in C (cello.c), complete the following steps.

To apply code patches on your software, you can use the patch utility.

The bello project is a Hello World file in Bash.

The following example contains only the bello shell script. Therefore, the resulting tar.gz archive has only one file in addition to the LICENSE file.

The pello project is a Hello World file in Python.

The following example contains only the pello.py program. Therefore, the resulting tar.gz archive has only one file in addition to the LICENSE file.

The cello project is a Hello World file in C.

The following example contains only the cello.c and the Makefile files. Therefore, the resulting tar.gz archive has two files in addition to the LICENSE file.

To configure the RPM packaging workspace, you can set up a directory layout by using the rpmdev-setuptree utility.

The following are the RPM packaging workspace directories created by using the rpmdev-setuptree utility:

The following are some of the directives that you can use in the Preamble section of the RPM spec file.

The Name, Version, and Release (NVR) directives comprise the file name of the RPM package in the name-version-release format.

You can display the NVR information for a specific package by querying RPM database by using the rpm command, for example:

# rpm -q bash
bash-4.4.19-7.el8.x86_64

Here, bash is the package name, 4.4.19 is the version, and 7.el8 is the release. The x86_64 marker is the package architecture. Unlike NVR, the architecture marker is not under direct control of the RPM packager, but is defined by the rpmbuild build environment. The exception to this is the architecture-independent noarch package.

The following are the items used in the Body section of the RPM spec file.

A spec file can contain advanced items, such as Scriptlets or Triggers.

Scriptlets and Triggers take effect at different points during the installation process on the end user’s system, not the build process.

You can create a spec file for each of the three implementations of the Hello World! program by using the rpmdev-newspec utility.

The original output spec file generated by the rpmdev-newspec utility represents a template that you must modify to provide necessary instructions for the rpmbuild utility. rpmbuild then uses these instructions to build an RPM package.

You have now written an entire spec file for the required program.

You can use the following example spec file for the bello program written in bash for your reference.

Name:           bello
Version:        0.1
Release:        1%{?dist}
Summary:        Hello World example implemented in bash script

License:        GPLv3+
URL:            https://www.example.com/%{name}
Source0:        https://www.example.com/%{name}/releases/%{name}-%{version}.tar.gz

Requires:       bash

BuildArch:      noarch

%description
The long-tail description for our Hello World Example implemented in
bash script.

%prep
%setup -q

%build

%install

mkdir -p %{buildroot}/%{_bindir}

install -m 0755 %{name} %{buildroot}/%{_bindir}/%{name}

%files
%license LICENSE
%{_bindir}/%{name}

%changelog
* Tue May 31 2016 Adam Miller <maxamillion@fedoraproject.org> - 0.1-1
- First bello package
- Example second item in the changelog for version-release 0.1-1

You can use the following example spec file for the pello program written in the Python programming language for your reference.

Name:           pello
Version:        0.1.1
Release:        1%{?dist}
Summary:        Hello World example implemented in Python

License:        GPLv3+
URL:            https://www.example.com/%{name}
Source0:        https://www.example.com/%{name}/releases/%{name}-%{version}.tar.gz

BuildRequires:  python
Requires:       python
Requires:       bash

BuildArch:      noarch

%description
The long-tail description for our Hello World Example implemented in Python.

%prep
%setup -q

%build

python -m compileall %{name}.py

%install

mkdir -p %{buildroot}/%{_bindir}
mkdir -p %{buildroot}/usr/lib/%{name}

cat > %{buildroot}/%{_bindir}/%{name} <<EOF
#!/bin/bash
/usr/bin/python /usr/lib/%{name}/%{name}.pyc
EOF

chmod 0755 %{buildroot}/%{_bindir}/%{name}

install -m 0644 %{name}.py* %{buildroot}/usr/lib/%{name}/

%files
%license LICENSE
%dir /usr/lib/%{name}/
%{_bindir}/%{name}
/usr/lib/%{name}/%{name}.py*

%changelog
* Tue May 31 2016 Adam Miller <maxamillion@fedoraproject.org> - 0.1.1-1
  - First pello package

This example of creating a wrapper script in-line in the spec file shows that the spec file itself is scriptable. This wrapper script executes the Python byte-compiled code by using the here document.

You can use the following example spec file for the cello program that was written in the C programming language for your reference.

Name:           cello
Version:        1.0
Release:        1%{?dist}
Summary:        Hello World example implemented in C

License:        GPLv3+
URL:            https://www.example.com/%{name}
Source0:        https://www.example.com/%{name}/releases/%{name}-%{version}.tar.gz

Patch0:         cello-output-first-patch.patch

BuildRequires:  gcc
BuildRequires:  make

%description
The long-tail description for our Hello World Example implemented in
C.

%prep
%setup -q

%patch0

%build
make %{?_smp_mflags}

%install
%make_install

%files
%license LICENSE
%{_bindir}/%{name}

%changelog
* Tue May 31 2016 Adam Miller <maxamillion@fedoraproject.org> - 1.0-1
- First cello package

You can install the cello program by using the %make_install macro. This is possible because the Makefile file for the cello program is available.

Building a Source RPM (SRPM) has the following advantages:

To rebuild a binary RPM from a source RPM (SRPM), use the rpmbuild command with the --rebuild option.

The output generated when creating the binary RPM is verbose, which is helpful for debugging. The output varies for different examples and corresponds to their spec files.

The resulting binary RPMs are located in the ~/rpmbuild/RPMS/YOURARCH directory, where YOURARCH is your architecture, or in the ~/rpmbuild/RPMS/noarch/ directory, if the package is not architecture-specific.

To build a binary RPM from its spec file, use the rpmbuild command with the -bb option.

In the following sections, investigate possible warnings and errors that can occur when checking an RPM for common errors on the example of the bello spec file and bello binary RPM.

$ rpmlint bello.spec
bello.spec: W: invalid-url Source0: https://www.example.com/bello/releases/bello-0.1.tar.gz HTTP Error 404: Not Found
0 packages and 1 specfiles checked; 0 errors, 1 warnings.

$ rpmlint ~/rpmbuild/SRPMS/bello-0.1-1.el8.src.rpm
bello.src: W: invalid-url URL: https://www.example.com/bello HTTP Error 404: Not Found
bello.src: W: invalid-url Source0: https://www.example.com/bello/releases/bello-0.1.tar.gz HTTP Error 404: Not Found
1 packages and 0 specfiles checked; 0 errors, 2 warnings.

$ rpmlint ~/rpmbuild/RPMS/noarch/bello-0.1-1.el8.noarch.rpm
bello.noarch: W: invalid-url URL: https://www.example.com/bello HTTP Error 404: Not Found
bello.noarch: W: no-documentation
bello.noarch: W: no-manual-page-for-binary bello
1 packages and 0 specfiles checked; 0 errors, 3 warnings.

In the following sections, investigate possible warnings and errors that can occur when validating RPM content on the example of the pello spec file and pello binary RPM.

$ rpmlint pello.spec
pello.spec:30: E: hardcoded-library-path in %{buildroot}/usr/lib/%{name}
pello.spec:34: E: hardcoded-library-path in /usr/lib/%{name}/%{name}.pyc
pello.spec:39: E: hardcoded-library-path in %{buildroot}/usr/lib/%{name}/
pello.spec:43: E: hardcoded-library-path in /usr/lib/%{name}/
pello.spec:45: E: hardcoded-library-path in /usr/lib/%{name}/%{name}.py*
pello.spec: W: invalid-url Source0: https://www.example.com/pello/releases/pello-0.1.2.tar.gz HTTP Error 404: Not Found
0 packages and 1 specfiles checked; 5 errors, 1 warnings.

$ rpmlint ~/rpmbuild/SRPMS/pello-0.1.2-1.el8.src.rpm
pello.src: W: invalid-url URL: https://www.example.com/pello HTTP Error 404: Not Found
pello.src:30: E: hardcoded-library-path in %{buildroot}/usr/lib/%{name}
pello.src:34: E: hardcoded-library-path in /usr/lib/%{name}/%{name}.pyc
pello.src:39: E: hardcoded-library-path in %{buildroot}/usr/lib/%{name}/
pello.src:43: E: hardcoded-library-path in /usr/lib/%{name}/
pello.src:45: E: hardcoded-library-path in /usr/lib/%{name}/%{name}.py*
pello.src: W: invalid-url Source0: https://www.example.com/pello/releases/pello-0.1.2.tar.gz HTTP Error 404: Not Found
1 packages and 0 specfiles checked; 5 errors, 2 warnings.

$ rpmlint ~/rpmbuild/RPMS/noarch/pello-0.1.2-1.el8.noarch.rpm
pello.noarch: W: invalid-url URL: https://www.example.com/pello HTTP Error 404: Not Found
pello.noarch: W: only-non-binary-in-usr-lib
pello.noarch: W: no-documentation
pello.noarch: E: non-executable-script /usr/lib/pello/pello.py 0644L /usr/bin/env
pello.noarch: W: no-manual-page-for-binary pello
1 packages and 0 specfiles checked; 1 errors, 4 warnings.

In the following sections, investigate possible warnings and errors that can occur when validating RPM content on the example of the cello spec file and cello binary RPM.

$ rpmlint ~/rpmbuild/SPECS/cello.spec
/home/admiller/rpmbuild/SPECS/cello.spec: W: invalid-url Source0: https://www.example.com/cello/releases/cello-1.0.tar.gz HTTP Error 404: Not Found
0 packages and 1 specfiles checked; 0 errors, 1 warnings.

$ rpmlint ~/rpmbuild/SRPMS/cello-1.0-1.el8.src.rpm
cello.src: W: invalid-url URL: https://www.example.com/cello HTTP Error 404: Not Found
cello.src: W: invalid-url Source0: https://www.example.com/cello/releases/cello-1.0.tar.gz HTTP Error 404: Not Found
1 packages and 0 specfiles checked; 0 errors, 2 warnings.

$ rpmlint ~/rpmbuild/RPMS/x86_64/cello-1.0-1.el8.x86_64.rpm
cello.x86_64: W: invalid-url URL: https://www.example.com/cello HTTP Error 404: Not Found
cello.x86_64: W: no-documentation
cello.x86_64: W: no-manual-page-for-binary cello
1 packages and 0 specfiles checked; 0 errors, 3 warnings.

Use the following procedure to create a GNU Privacy Guard (GPG) key required for signing packages.

To be able to sign an RPM package, you need to specify the %_gpg_name RPM macro.

The following procedure describes how to configure RPM for signing a package.

The most usual case is when a package is built without a signature. The signature is added just before the release of the package.

To add a signature to an RPM package, use the --addsign option provided by the rpm-sign package.

The following section describes how to create a custom macro.

All whitespace surrounding <body> is removed. Name may be composed of alphanumeric characters, and the character _ and must be at least 3 characters in length. Inclusion of the (opts) field is optional:

This section describes how to build packages with source code tarballs using different variants of the %setup macro. Note that the macro variants can be combined. The rpmbuild output illustrates standard behavior of the %setup macro. At the beginning of each phase, the macro outputs Executing(%…​), as shown in the below example.

Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.DhddsG

cd '/builddir/build/BUILD'
rm -rf 'cello-1.0'
/usr/bin/gzip -dc '/builddir/build/SOURCES/cello-1.0.tar.gz' | /usr/bin/tar -xof -
STATUS=$?
if [ $STATUS -ne 0 ]; then
  exit $STATUS
fi
cd 'cello-1.0'
/usr/bin/chmod -Rf a+rX,u+w,g-w,o-w .

The %setup macro:

Name: cello
Source0: https://example.com/%{name}/release/hello-%{version}.tar.gz
…
%prep
%setup -n hello

/usr/bin/mkdir -p cello-1.0
cd 'cello-1.0'

rm -rf 'cello-1.0'

/usr/bin/gzip -dc '/builddir/build/SOURCES/cello-1.0.tar.gz' | /usr/bin/tar -xvvof -

Source0: https://example.com/%{name}/release/%{name}-%{version}.tar.gz
Source1: examples.tar.gz
…
%prep
%setup -a 1

Source0: https://example.com/%{name}/release/%{name}-%{version}.tar.gz
Source1: %{name}-%{version}-examples.tar.gz
…
%prep
%setup -b 1

The following table lists advanced RPM Macros that are needed in the %files section of a spec file.

Red Hat Enterprise Linux provides multiple built-in RPM macros.

Different distributions provide different sets of recommended RPM macros based on the language implementation of the software being packaged or the specific guidelines of the distribution.

The sets of recommended RPM macros are often provided as RPM packages, ready to be installed with the yum package manager.

Once installed, the macro files can be found in the /usr/lib/rpm/macros.d/ directory.

The above output displays the raw RPM macro definitions.

You can override the distribution macros in the ~/.rpmmacros file with your custom macros. Any changes that you make affect every build on your machine.

You can create the directory from the example above, including all subdirectories through the rpmdev-setuptree utility. The value of this macro is by default ~/rpmbuild.

%_smp_mflags -l3

The macro above is often used to pass to Makefile, for example make %{?_smp_mflags}, and to set a number of concurrent processes during the build phase. By default, it is set to -jX, where X is a number of cores. If you alter the number of cores, you can speed up or slow down a build of packages.

The Epoch directive enables to define weighted dependencies based on version numbers.

If this directive is not listed in the RPM spec file, the Epoch directive is not set at all. This is contrary to common belief that not setting Epoch results in an Epoch of 0. However, the yum utility treats an unset Epoch as the same as an Epoch of 0 for the purposes of depsolving.

However, listing Epoch in a spec file is usually omitted because in majority of cases introducing an Epoch value skews the expected RPM behavior when comparing versions of packages.

Using of Epoch is thus quite rare. However, Epoch is typically used to resolve an upgrade ordering issue. The issue can appear as a side effect of upstream change in software version number schemes or versions incorporating alphabetical characters that cannot always be compared reliably based on encoding.

Scriptlets are a series of RPM directives that are executed before or after packages are installed or deleted.

Use Scriptlets only for tasks that cannot be done at build time or in an start up script.

A set of common Scriptlet directives exists. They are similar to the spec file section headers, such as %build or %install. They are defined by multi-line segments of code, which are often written as a standard POSIX shell script. However, they can also be written in other programming languages that RPM for the target machine’s distribution accepts. RPM Documentation includes an exhaustive list of available languages.

The following table includes Scriptlet directives listed in their execution order. Note that a package containing the scripts is installed between the %pre and %post directive, and it is uninstalled between the %preun and %postun directive.

The following procedure describes how to turn off the execution of any scriptlet using the rpm command together with the --no_scriptlet_name_ option.

The Scriptlets directives also work with RPM macros.

The following example shows the use of systemd scriptlet macro, which ensures that systemd is notified about a new unit file.

$ rpm --showrc | grep systemd
-14: __transaction_systemd_inhibit      %{__plugindir}/systemd_inhibit.so
-14: _journalcatalogdir /usr/lib/systemd/catalog
-14: _presetdir /usr/lib/systemd/system-preset
-14: _unitdir   /usr/lib/systemd/system
-14: _userunitdir       /usr/lib/systemd/user
/usr/lib/systemd/systemd-binfmt %{?*} >/dev/null 2>&1 || :
/usr/lib/systemd/systemd-sysctl %{?*} >/dev/null 2>&1 || :
-14: systemd_post
-14: systemd_postun
-14: systemd_postun_with_restart
-14: systemd_preun
-14: systemd_requires
Requires(post): systemd
Requires(preun): systemd
Requires(postun): systemd
-14: systemd_user_post  %systemd_post --user --global %{?*}
-14: systemd_user_postun        %{nil}
-14: systemd_user_postun_with_restart   %{nil}
-14: systemd_user_preun
systemd-sysusers %{?*} >/dev/null 2>&1 || :
echo %{?*} | systemd-sysusers - >/dev/null 2>&1 || :
systemd-tmpfiles --create %{?*} >/dev/null 2>&1 || :

$ rpm --eval %{systemd_post}

if [ $1 -eq 1 ] ; then
        # Initial installation
        systemctl preset  >/dev/null 2>&1 || :
fi

$ rpm --eval %{systemd_postun}

systemctl daemon-reload >/dev/null 2>&1 || :

$ rpm --eval %{systemd_preun}

if [ $1 -eq 0 ] ; then
        # Package removal, not upgrade
        systemctl --no-reload disable  > /dev/null 2>&1 || :
        systemctl stop  > /dev/null 2>&1 || :
fi

Triggers are RPM directives which provide a method for interaction during package installation and uninstallation.

The order of execution on a single package upgrade and the details for each existing Triggers are listed below:

all-%pretrans
…​
any-%triggerprein (%triggerprein from other packages set off by new install)
new-%triggerprein
new-%pre      for new version of package being installed
…​           (all new files are installed)
new-%post     for new version of package being installed

any-%triggerin (%triggerin from other packages set off by new install)
new-%triggerin
old-%triggerun
any-%triggerun (%triggerun from other packages set off by old uninstall)

old-%preun    for old version of package being removed
…​           (all old files are removed)
old-%postun   for old version of package being removed

old-%triggerpostun
any-%triggerpostun (%triggerpostun from other packages set off by old un
            install)
…​
all-%posttrans

The above items are found in the /usr/share/doc/rpm-4.*/triggers file.

The -p scriptlet option in a spec file enables the user to invoke a specific interpreter instead of the default shell scripts interpreter (-p /bin/sh).

The following procedure describes how to create a script, which prints out a message after installation of the pello.py program:

%post -p /usr/bin/python3

%post -p <lua>

RPM conditionals use the following syntax:

If expression is true, then do some action:

%if expression
…​
%endif

If expression is true, then do some action, in other case, do another action:

%if expression
…​
%else
…​
%endif

The following examples shows the usage of %if RPM conditionals.

%if 0%{?rhel} == 8
sed -i '/AS_FUNCTION_DESCRIBE/ s/^/#/' configure.in
sed -i '/AS_FUNCTION_DESCRIBE/ s/^/#/' acinclude.m4
%endif

This conditional handles compatibility between RHEL 8 and other operating systems in terms of support of the AS_FUNCTION_DESCRIBE macro. If the package is built for RHEL, the %rhel macro is defined, and it is expanded to RHEL version. If its value is 8, meaning the package is build for RHEL 8, then the references to AS_FUNCTION_DESCRIBE, which is not supported by RHEL 8, are deleted from autoconfig scripts.

%define ruby_archive %{name}-%{ruby_version}
%if 0%{?milestone:1}%{?revision:1} != 0
%define ruby_archive %{ruby_archive}-%{?milestone}%{?!milestone:%{?revision:r%{revision}}}
%endif

This conditional handles definition of macros. If the %milestone or the %revision macros are set, the %ruby_archive macro, which defines the name of the upstream tarball, is redefined.

The %ifarch conditional, %ifnarch conditional and %ifos conditional are specialized variants of the %if conditionals. These variants are commonly used, hence they have their own macros.

%ifarch i386 sparc
…​
%endif

All the contents of the spec file between %ifarch and %endif are processed only on the 32-bit AMD and Intel architectures or Sun SPARC-based systems.

%ifnarch alpha
…​
%endif

All the contents of the spec file between %ifnarch and %endif are processed only if not done on a Digital Alpha/AXP-based system.

%ifos linux
…​
%endif

All the contents of the spec file between %ifos and %endif are processed only if the build was done on a Linux system.

A spec file contains instructions that the rpmbuild utility uses to build an RPM. The instructions are included in a series of sections. A spec file has two main parts in which the sections are defined:

An RPM SPEC file for Python projects has some specifics compared to non-Python RPM SPEC files. Most notably, a name of any RPM package of a Python library must always include the prefix determining the version, for example, python3 for Python 3.6, python38 for Python 3.8, python39 for Python 3.9, python3.11 for Python 3.11, or python3.12 for Python 3.12.

Other specifics are shown in the following spec file example for the python3-detox package. For description of such specifics, see the notes below the example.

%global modname detox                                                1

Name:           python3-detox                                        2
Version:        0.12
Release:        4%{?dist}
Summary:        Distributing activities of the tox tool
License:        MIT
URL:            https://pypi.io/project/detox
Source0:        https://pypi.io/packages/source/d/%{modname}/%{modname}-%{version}.tar.gz

BuildArch:      noarch

BuildRequires:  python36-devel                                       3
BuildRequires:  python3-setuptools
BuildRequires:  python36-rpm-macros
BuildRequires:  python3-six
BuildRequires:  python3-tox
BuildRequires:  python3-py
BuildRequires:  python3-eventlet

%?python_enable_dependency_generator                                 4

%description

Detox is the distributed version of the tox python testing tool. It makes efficient use of multiple CPUs by running all possible activities in parallel.
Detox has the same options and configuration that tox has, so after installation you can run it in the same way and with the same options that you use for tox.

    $ detox

%prep
%autosetup -n %{modname}-%{version}

%build
%py3_build                                                           5

%install
%py3_install

%check
%{__python3} setup.py test                                           6

%files -n python3-%{modname}
%doc CHANGELOG
%license LICENSE
%{_bindir}/detox
%{python3_sitelib}/%{modname}/
%{python3_sitelib}/%{modname}-%{version}*

%changelog
...

In a spec file, always use the macros that are described in the following Macros for Python 3 RPMs table rather than hardcoding their values.

In macro names, always use python3 or python2 instead of unversioned python. Configure the particular Python 3 version in the BuildRequires section of the SPEC file to python36-rpm-macros, python38-rpm-macros, python39-rpm-macros, python3.11-rpm-macros, or python3.12-rpm-macros.

When packaging a Python project, make sure that the following directories are included in the resulting RPM if these directories are present:

From these directories, the RPM build process automatically generates virtual pythonX.Ydist provides, for example, python3.6dist(detox). These virtual provides are used by packages that are specified by the %python_enable_dependency_generator macro.

Modify interpreter directives in the Python scripts that cause the build errors at RPM build time.

If the packaged Python scripts require a version other than Python 3.6, adjust the preceding commands to include the required version.

By default, interpreter directives in the form of /usr/bin/python3 are replaced with interpreter directives pointing to Python from the platform-python package, which is used for system tools with Red Hat Enterprise Linux. You can change the /usr/bin/python3 interpreter directives in your custom packages to point to a specific version of Python that you have installed from the AppStream repository.

%undefine __brp_mangle_shebangs

Ruby is a dynamic, interpreted, reflective, object-oriented, general-purpose programming language.

Programs written in Ruby are typically packaged using the RubyGems project, which provides a specific Ruby packaging format.

Packages created by RubyGems are called gems, and they can be re-packaged into RPM as well.

RubyGems represent Ruby’s own packaging format. However, RubyGems contain metadata similar to those needed by RPM, which enables the conversion from RubyGems to RPM.

According to Ruby Packaging Guidelines, it is possible to re-package RubyGems packages into RPM in this way:

RubyGems use similar terminology as RPM, such as spec files, package names, dependencies and other items.

To fit into the rest of RHEL RPM distribution, packages created by RubyGems must follow the conventions listed below:

To create a source RPM for a RubyGems package, the following files are needed:

The following sections describe how to create RPM packages from packages created by RubyGems.

%prep
%setup -q -n  %{gem_name}-%{version}

# Modify the gemspec if necessary
# Also apply patches to code if necessary
%patch0 -p1

%build
# Create the gem as gem install only works on a gem file
gem build ../%{gem_name}-%{version}.gemspec

# %%gem_install compiles any C extensions and installs the gem into ./%%gem_dir
# by default, so that we can move it into the buildroot in %%install
%gem_install

%install
mkdir -p %{buildroot}%{gem_dir}
cp -a ./%{gem_dir}/* %{buildroot}%{gem_dir}/

# If there were programs installed:
mkdir -p %{buildroot}%{_bindir}
cp -a ./%{_bindir}/* %{buildroot}%{_bindir}

# If there are C extensions, copy them to the extdir.
mkdir -p %{buildroot}%{gem_extdir_mri}
cp -a .%{gem_extdir_mri}/{gem.build_complete,*.so} %{buildroot}%{gem_extdir_mri}/

$ gem install gem2rpm

The most frequently occurring Perl-related build dependencies used in BuildRequires: are :

If a specific Perl module is required at build time, use the following procedure:

To limit your package to a specific Perl version, follow this procedure:

Red Hat provides multiple Perl interpreters, which are not fully compatible. Therefore, any package that delivers a Perl module must use at run time the same Perl interpreter that was used at build time.

To ensure this, follow the procedure below:

By default, Weak dependencies are treated similarly to regular Requires:. Matching packages are included in the YUM transaction. If adding the package leads to an error, YUM by default ignores the dependency. Hence, users can exclude packages that would be added by Weak dependencies or remove them later.

Typical use cases for Weak dependencies are:

Hints are by default ignored by YUM. They can be used by GUI tools to offer add-on packages that are not installed by default but can be useful in combination with the installed packages.

Do not use Hints for the requirements of the main use cases of a package. Include such requirements in the strong or Weak dependencies instead.

Note, the normal rules of dependency resolution are not influenced by this feature. For example, Weak dependencies cannot enforce an older version of a package to be chosen.

If there are multiple providers for a dependency, the requiring package can add a Suggests: to provide a hint to the dependency resolver about which option is preferred.

Enhances: is only used when the main package and other providers agree that adding the hint to the required package is for some reason the cleaner solution.

Package A: Requires: mysql

Package mariadb: Provides: mysql

Package community-mysql: Provides: mysql

Suggests: mariadb to Package A.

Forward dependencies are, similarly to Requires, evaluated for packages that are being installed. The best of the matching packages are also installed.

In general, prefer Forward dependencies. Add the dependency to the package when getting the other package added to the system.

For Backward dependencies, the packages containing the dependency are installed if a matching package is installed as well.

Backward dependencies are mainly designed for third party vendors who can attach their plug-ins, add-ons, or extensions to distribution or other third party packages.

Boolean expressions are always enclosed with parenthesis.

They are build out of normal dependencies:

RPM 4.13 introduced the following boolean operators:

RPM 4.14 introduced the following additional boolean operators:

Operands themselves can be used as boolean expressions, as shown in the below examples.

Note that in such case, operands also need to be surrounded by parenthesis. You can chain the and and or operators together repeating the same operator with only one set of surrounding parenthesis.

Requires: (pkgA or pkgB or pkgC)

Requires: (pkgA or (pkgB and pkgC))

Supplements: (foo and (lang-support-cz or lang-support-all))

Requires: (pkgA with capB) or (pkgB without capA)

Supplements: ((driverA and driverA-tools) unless driverB)

Recommends: myPkg-langCZ and (font1-langCZ or font2-langCZ) if langsupportCZ

Using Boolean dependencies does not change the semantic of regular dependencies.

If Boolean dependencies are used, checking for one match all names are checked and the boolean value of there being a match is then aggregated over the Boolean operators.

The if operator is also returning a boolean value, which is usually close to what the intuitive understanding is. However, the below examples show that in some cases intuitive understanding of if can be misleading.

Requires: (pkgA if pkgB)

Conflicts: (pkgA if pkgB)

Conflicts: (pkgA and pkgB)

Requires: ((pkgA if pkgB) or pkgC or pkg)

Requires: ((pkgA and pkgB) or pkgC or pkg)

File triggers have the following syntax:

%file_trigger_tag [FILE_TRIGGER_OPTIONS] — PATHPREFIX…​
body_of_script

Where:

file_trigger_tag defines a type of file trigger. Allowed types are:

FILE_TRIGGER_OPTIONS have the same purpose as RPM scriptlets options, except for the -P option.

The priority of a trigger is defined by a number. The bigger number, the sooner the file trigger script is executed. Triggers with priority greater than 100000 are executed before standard scriptlets, and the other triggers are executed after standard scriptlets. The default priority is set to 1000000.

Every file trigger of each type must contain one or more path prefixes and scripts.

The following example shows the File triggers syntax:

%filetriggerin — /lib, /lib64, /usr/lib, /usr/lib64
/usr/sbin/ldconfig

This file trigger executes /usr/bin/ldconfig directly after the installation of a package that contains a file having a path starting with /usr/lib or /lib. The file trigger is executed just once even if the package includes multiple files with the path starting with /usr/lib or /lib. However, all file names starting with /usr/lib or /lib are passed to standard input of trigger script so that you can filter inside of your script as shown below:

%filetriggerin — /lib, /lib64, /usr/lib, /usr/lib64
grep "foo" && /usr/sbin/ldconfig

This file trigger executes /usr/bin/ldconfig for each package containing files starting with /usr/lib and containing foo at the same time. Note that the prefix-matched files include all types of files including regular files, directories, symlinks and others.

File triggers have two main types:

File triggers are further divided based on the time of execution as follows:

The following example shows a real-world usage of File triggers within the glibc package.

In RHEL 8, File triggers are implemented in glibc to call the ldconfig command at the end of an installation or uninstallation transaction.

This is ensured by including the following scriptlets in the glibc’s SPEC file:

%transfiletriggerin common -P 2000000 – /lib /usr/lib /lib64 /usr/lib64
/sbin/ldconfig
%end
%transfiletriggerpostun common -P 2000000 – /lib /usr/lib /lib64 /usr/lib64
/sbin/ldconfig
%end

Therefore, if you install or uninstall multiple packages, the ldconfig cache is updated for all installed libraries after the whole transaction is finished. Consequently, it is no longer necessary to include the scriptlets calling ldconfig in RPM spec files of individual packages. This improves the performance compared to RHEL 7, where the cache was updated for each package separately.

Several RPM tags exist in both 64-bit versions and previous 32-bit versions. Note that the 64-bit versions have the LONG string in front of their name.

The LONG extensions are always enabled on the command line. If you previously used scripts containing the rpm -q --qf command, you can add long to the name of such tags:

rpm -qp --qf="[%{filenames} %{longfilesizes}\n]"