Chapter 4. Packaging software

4.1. Setting up RPM packaging workspace
Link kopieren

To build RPM packages, you must first create a special workspace that consists of directories used for different packaging purposes.

4.1.1. Configuring RPM packaging workspace
Link kopieren

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

Prerequisites

You installed the rpmdevtools package, which provides utilities for packaging RPMs:
```
dnf install rpmdevtools
```
```
# dnf install rpmdevtools
```
Copy to Clipboard Toggle word wrap

Procedure

Run the rpmdev-setuptree utility:

rpmdev-setuptree
tree ~/rpmbuild/

$ rpmdev-setuptree

$ tree ~/rpmbuild/
/home/user/rpmbuild/
|-- BUILD
|-- RPMS
|-- SOURCES
|-- SPECS
`-- SRPMS

5 directories, 0 files

Copy to Clipboard

Toggle word wrap

4.1.2. RPM packaging workspace directories
Link kopieren

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

Expand

Table 4.1. RPM packaging workspace directories
Directory	Purpose
`BUILD`	Contains build artifacts compiled from the source files from the `SOURCES` directory.
`RPMS`	Binary RPMs are created under the `RPMS` directory in subdirectories for different architectures. For example, in the `x86_64` or `noarch` subdirectory.
`SOURCES`	Contains compressed source code archives and patches. The `rpmbuild` command then searches for these archives and patches in this directory.
`SPECS`	Contains `spec` files created by the packager. These files are then used for building packages.
`SRPMS`	When you use the `rpmbuild` command to build an SRPM instead of a binary RPM, the resulting SRPM is created under this directory.

4.2. About spec files
Link kopieren

A spec file is a file with instructions that the rpmbuild utility uses to build an RPM package. This file provides necessary information to the build system by defining instructions in a series of sections. These sections are defined in the Preamble and the Body part of the spec file:

The Preamble section contains a series of metadata items that are used in the Body section.
The Body section represents the main part of the instructions.

4.2.1. Preamble items
Link kopieren

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

Expand

Table 4.2. The Preamble section directives
Directive	Definition
`Name`	A base name of the package that must match the `spec` file name.
`Version`	An upstream version number of the software.
`Release`	The number of times the version of the package was released. Set the initial value to `1%{?dist}` and increase it with each new release of the package. Reset to `1` when a new `Version` of the software is built.
`Summary`	A brief one-line summary of the package.
`License`	A license of the software being packaged. The exact format for how to label the `License` in your `spec` file varies depending on which RPM-based Linux distribution guidelines you are following, for example, GPLv3+.
`URL`	A full URL for more information about the software, for example, an upstream project website for the software being packaged.
`Source`	A path or URL to the compressed archive of the unpatched upstream source code. This link must point to an accessible and reliable storage of the archive, for example, the upstream page, not the packager’s local storage. You can apply the `Source` directive either with or without numbers at the end of the directive name. If there is no number given, the number is assigned to the entry internally. You can also give the numbers explicitly, for example, `Source0`, `Source1`, `Source2`, `Source3`, and so on.
`Patch`	A name of the first patch to apply to the source code, if necessary. You can apply the `Patch` directive either with or without numbers at the end of the directive name. If there is no number given, the number is assigned to the entry internally. You can also give the numbers explicitly, for example, `Patch0`, `Patch1`, `Patch2`, `Patch3`, and so on. You can apply the patches individually by using the `%patch0`, `%patch1`, `%patch2` macro, and so on. Macros are applied within the `%prep` directive in the Body section of the RPM `spec` file. Alternatively, you can use the `%autopatch` macro that automatically applies all patches in the order they are given in the `spec` file.
`BuildArch`	An architecture that the software will be built for. If the software is not architecture-dependent, for example, if you wrote the software entirely in an interpreted programming language, set the value to `BuildArch: noarch`. If you do not set this value, the software automatically inherits the architecture of the machine on which it is built, for example, `x86_64`.
`BuildRequires`	A comma- or whitespace-separated list of packages required to build the program written in a compiled language. There can be multiple entries of `BuildRequires`, each on its own line in the SPEC file.
`Requires`	A comma- or whitespace-separated list of packages required by the software to run once installed. There can be multiple entries of `Requires`, each on its own line in the `spec` file.
`ExcludeArch`	If a piece of software cannot operate on a specific processor architecture, you can exclude this architecture in the `ExcludeArch` directive.
`Conflicts`	A comma- or whitespace-separated list of packages that must not be installed on the system in order for your software to function properly when installed. There can be multiple entries of `Conflicts`, each on its own line in the `spec` file.
`Obsoletes`	The `Obsoletes` directive changes the way updates work depending on the following factors: If you use the `rpm` command directly on a command line, it removes all packages that match obsoletes of packages being installed, or the update is performed by an updates or dependency solver. If you use the updates or dependency resolver (DNF), packages containing matching `Obsoletes:` are added as updates and replace the matching packages.
`Provides`	If you add the `Provides` directive to the package, this package can be referred to by dependencies other than its name.

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

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

Copy to Clipboard

Toggle word wrap

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.

4.2.2. Body items
Link kopieren

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

Expand

Table 4.3. The Body section items
Directive	Definition
`%description`	A full description of the software packaged in the RPM. This description can span multiple lines and can be broken into paragraphs.
`%prep`	A command or series of commands to prepare the software for building, for example, for unpacking the archive in the `Source` directive. The `%prep` directive can contain a shell script.
`%build`	A command or series of commands for building the software into machine code (for compiled languages) or bytecode (for some interpreted languages).
`%install`	A command or series of commands that the `rpmbuild` utility will use to install the software into the `BUILDROOT` directory once the software has been built. These commands copy the desired build artifacts from the `%_builddir` directory, where the build happens, to the `%buildroot` directory that contains the directory structure with the files to be packaged. This includes copying files from `~/rpmbuild/BUILD` to `~/rpmbuild/BUILDROOT` and creating the necessary directories in `~/rpmbuild/BUILDROOT`. The `%install` directory is an empty `chroot` base directory, which resembles the end user’s `root` directory. Here you can create any directories that will contain the installed files. To create such directories, you can use RPM macros without having to hardcode the paths. Note that `%install` is only run when you create a package, not when you install it. For more information, see Working with spec files.
`%check`	A command or series of commands for testing the software, for example, unit tests.
`%files`	A list of files, provided by the RPM package, to be installed in the user’s system and their full path location on the system. During the build, if there are files in the `%buildroot` directory that are not listed in `%files`, you will receive a warning about possible unpackaged files. Within the `%files` section, you can indicate the role of various files by using built-in macros. This is useful for querying the package file manifest metadata by using the `rpm` command. For example, to indicate that the `LICENSE` file is a software license file, use the `%license` macro.
`%changelog`	A record of changes that happened to the package between different `Version` or `Release` builds. These changes include a list of date-stamped entries for each Version-Release of the package. These entries log packaging changes, not software changes, for example, adding a patch or changing the build procedure in the `%build` section.

4.2.3. Advanced items
Link kopieren

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.

4.3. BuildRoots
Link kopieren

In the context of RPM packaging, buildroot is a chroot environment. The build artifacts are placed here by using the same file system hierarchy as the future hierarchy in the end user’s system, with buildroot acting as the root directory. The placement of build artifacts must comply with the file system hierarchy standard of the end user’s system.

The files in buildroot are later put into a cpio archive, which becomes the main part of the RPM. When RPM is installed on the end user’s system, these files are extracted in the root directory, preserving the correct hierarchy.

Note

The rpmbuild program has its own defaults. Overriding these defaults can cause certain issues. Therefore, avoid defining your own value of the buildroot macro. Use the default %{buildroot} macro instead.

4.4. RPM macros
Link kopieren

An rpm macro is a straight text substitution that can be conditionally assigned based on the optional evaluation of a statement when certain built-in functionality is used. Therefore, RPM can perform text substitutions for you.

For example, you can define Version of the packaged software only once in the %{version} macro, and use this macro throughout the spec file. Every occurrence is automatically substituted by Version that you defined in the macro.

Note

If you see an unfamiliar macro, you can evaluate it with the following command:

rpm --eval %{MACRO}

$ rpm --eval %{MACRO}

Copy to Clipboard

Toggle word wrap

For example, to evaluate the %{_bindir} and %{_libexecdir} macros, enter:

rpm --eval %{_bindir}
rpm --eval %{_libexecdir}

$ rpm --eval %{_bindir}
/usr/bin

$ rpm --eval %{_libexecdir}
/usr/libexec

Copy to Clipboard

Toggle word wrap

4.5. Working with spec files
Link kopieren

To package new software, you must create a spec file. You can create the spec file either of the following ways:

Write the new spec file manually from scratch.
Use the rpmdev-newspec utility. This utility creates an unpopulated spec file, where you fill the necessary directives and fields.

Note

Some programmer-focused text editors pre-populate a new spec file with their own spec template. The rpmdev-newspec utility provides an editor-agnostic method.

4.5.1. Creating a new spec file for sample Bash, Python, and C programs
Link kopieren

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

Prerequisites

The following Hello World! program implementations were placed into the ~/rpmbuild/SOURCES directory:

Procedure

Navigate to the ~/rpmbuild/SPECS directory:
```
cd ~/rpmbuild/SPECS
```
```
$ cd ~/rpmbuild/SPECS
```
Copy to Clipboard Toggle word wrap

Create a spec file for each of the three implementations of the Hello World! program:

rpmdev-newspec bello
rpmdev-newspec cello
rpmdev-newspec pello

$ rpmdev-newspec bello
bello.spec created; type minimal, rpm version >= 4.11.

$ rpmdev-newspec cello
cello.spec created; type minimal, rpm version >= 4.11.

$ rpmdev-newspec pello
pello.spec created; type minimal, rpm version >= 4.11.

Copy to Clipboard

Toggle word wrap

The ~/rpmbuild/SPECS/ directory now contains three spec files named bello.spec, cello.spec, and pello.spec.

Examine the created files.
The directives in the files represent those described in About spec files. In the following sections, you will populate a particular section in the output files of rpmdev-newspec.

4.5.2. Modifying an original spec file
Link kopieren

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.

Prerequisites

The unpopulated ~/rpmbuild/SPECS/<name>.spec spec file was created by using the rpmdev-newspec utility. For more information, see Creating a new spec file for sample Bash, Python, and C programs.

Procedure

Open the ~/rpmbuild/SPECS/<name>.spec file provided by the rpmdev-newspec utility.
Populate the following directives of the spec file Preamble section:
Name
Name was already specified as an argument to rpmdev-newspec.
Version
Set Version to match the upstream release version of the source code.
Release
Release is automatically set to 1%{?dist}, which is initially 1.
Summary
Enter a one-line explanation of the package.
License
Enter the software license associated with the source code.
URL
Enter the URL to the upstream software website. For consistency, utilize the %{name} RPM macro variable and use the https://example.com/%{name} format.
Source
Enter the URL to the upstream software source code. Link directly to the software version being packaged.
Note
The example URLs in this documentation include hard-coded values that could possibly change in the future. Similarly, the release version can change as well. To simplify these potential future changes, use the %{name} and %{version} macros. By using these macros, you need to update only one field in the spec file.
BuildRequires
Specify build-time dependencies for the package.
Requires
Specify run-time dependencies for the package.
BuildArch
Specify the software architecture.
Populate the following directives of the spec file Body section. You can think of these directives as section headings, because these directives can define multi-line, multi-instruction, or scripted tasks to occur.
%description
Enter the full description of the software.
%prep
Enter a command or series of commands to prepare software for building.
%build
Enter a command or series of commands for building software.
%install
Enter a command or series of commands that instruct the rpmbuild command on how to install the software into the BUILDROOT directory.
%files
Specify the list of files, provided by the RPM package, to be installed on your system.
%changelog
Enter the list of datestamped entries for each Version-Release of the package.
Start the first line of the %changelog section with an asterisk (*) character followed by Day-of-Week Month Day Year Name Surname <email> - Version-Release.
For the actual change entry, follow these rules:
Each change entry can contain multiple items, one for each change.
Each item starts on a new line.
Each item begins with a hyphen (-) character.

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

4.5.3. An example spec file for a sample Bash program
Link kopieren

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

An example spec file for the bello program written in bash

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

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

Copy to Clipboard

Toggle word wrap

The BuildRequires directive, which specifies build-time dependencies for the package, was deleted because there is no building step for bello. Bash is a raw interpreted programming language, and the files are just installed to their location on the system.
The Requires directive, which specifies run-time dependencies for the package, includes only bash, because the bello script requires only the bash shell environment to execute.
The %build section, which specifies how to build the software, is blank, because the bash script does not need to be built.

Note

To install bello, you must create the destination directory and install the executable bash script file there. Therefore, you can use the install command in the %install section. You can use RPM macros to do this without hardcoding paths.

4.5.4. An example spec file for a sample Python program
Link kopieren

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

An example spec file for the pello program written in Python

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

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

Copy to Clipboard

Toggle word wrap

The Requires directive, which specifies run-time dependencies for the package, includes two packages:
- The python package required to execute the byte-compiled code at runtime.
- The bash package required to execute the small entry-point script.
The BuildRequires directive, which specifies build-time dependencies for the package, includes only the python package. The pello program requires python to perform the byte-compile build process.
The %build section, which specifies how to build the software, creates a byte-compiled version of the script. Note that in real-world packaging, it is usually done automatically, depending on the distribution used.
The %install section corresponds to the fact that you must install the byte-compiled file into a library directory on the system so that it can be accessed.

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.

4.5.5. An example spec file for a sample C program
Link kopieren

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

An example spec file for the cello program written in C

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

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

Copy to Clipboard

Toggle word wrap

The BuildRequires directive, which specifies build-time dependencies for the package, includes the following packages required to perform the compilation build process:
- gcc
- make
The Requires directive, which specifies run-time dependencies for the package, is omitted in this example. All runtime requirements are handled by rpmbuild, and the cello program does not require anything outside of the core C standard libraries.
The %build section reflects the fact that in this example the Makefile file for the cello program was written. Therefore, you can use the GNU make command. However, you must remove the call to %configure because you did not provide a configure script.

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.

4.6. Building RPMs
Link kopieren

You can build RPM packages by using the rpmbuild command. When using this command, a certain directory and file structure is expected, which is the same as the structure that was set up by the rpmdev-setuptree utility.

Different use cases and desired outcomes require different combinations of arguments to the rpmbuild command. The following are the main use cases:

Building source RPMs.
Building binary RPMs:
- Rebuilding a binary RPM from a source RPM.
- Building a binary RPM from the spec file.

4.6.1. Building a source RPM
Link kopieren

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

You can preserve the exact source of a certain Name-Version-Release of an RPM file that was deployed to an environment. This includes the exact spec file, the source code, and all relevant patches. This is useful for tracking and debugging purposes.
You can build a binary RPM on a different hardware platform or architecture.

Prerequisites

You have installed the rpmbuild utility on your system:
```
dnf install rpm-build
```
```
# dnf install rpm-build
```
Copy to Clipboard Toggle word wrap
The following Hello World! implementations were placed into the ~/rpmbuild/SOURCES/ directory:
A spec file for the program that you want to package exists.

Procedure

Navigate to the ~/rpmbuild/SPECS/ directive, which contains the created spec file:
```
cd ~/rpmbuild/SPECS/
```
```
$ cd ~/rpmbuild/SPECS/
```
Copy to Clipboard Toggle word wrap

Build the source RPM by entering the rpmbuild command with the specified spec file:

rpmbuild -bs <specfile>

$ rpmbuild -bs <specfile>

Copy to Clipboard

Toggle word wrap

The -bs option stands for the build source.

For example, to build source RPMs for the bello, pello, and cello programs, enter:

rpmbuild -bs bello.spec
rpmbuild -bs pello.spec
rpmbuild -bs cello.spec

$ rpmbuild -bs bello.spec
Wrote: /home/admiller/rpmbuild/SRPMS/bello-0.1-1.el8.src.rpm

$ rpmbuild -bs pello.spec
Wrote: /home/admiller/rpmbuild/SRPMS/pello-0.1.2-1.el8.src.rpm

$ rpmbuild -bs cello.spec
Wrote: /home/admiller/rpmbuild/SRPMS/cello-1.0-1.el8.src.rpm

Copy to Clipboard

Toggle word wrap

Verification

Verify that the rpmbuild/SRPMS directory includes the resulting source RPMs. The directory is a part of the structure expected by rpmbuild.

4.6.2. Rebuilding a binary RPM from a source RPM
Link kopieren

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 either of the following directories:

~/rpmbuild/RPMS/YOURARCH, where YOURARCH is your architecture.
~/rpmbuild/RPMS/noarch/, if the package is not architecture-specific.

Prerequisites

You have installed the rpmbuild utility on your system:
```
dnf install rpm-build
```
```
# dnf install rpm-build
```
Copy to Clipboard Toggle word wrap

Procedure

Navigate to the ~/rpmbuild/SRPMS/ directive, which contains the SRPM:
```
cd ~/rpmbuild/SRPMS/
```
```
$ cd ~/rpmbuild/SRPMS/
```
Copy to Clipboard Toggle word wrap

Rebuild the binary RPM from the SRPM:

rpmbuild --rebuild <srpm>

$ rpmbuild --rebuild <srpm>

Copy to Clipboard

Toggle word wrap

For example, to rebuild bello, pello, and cello from their SRPMs, enter:

rpmbuild --rebuild bello-0.1-1.el8.src.rpm
rpmbuild --rebuild pello-0.1.2-1.el8.src.rpm
rpmbuild --rebuild cello-1.0-1.el8.src.rpm

$ rpmbuild --rebuild bello-0.1-1.el8.src.rpm
[output truncated]

$ rpmbuild --rebuild pello-0.1.2-1.el8.src.rpm
[output truncated]

$ rpmbuild --rebuild cello-1.0-1.el8.src.rpm
[output truncated]

Copy to Clipboard

Toggle word wrap

Note

Invoking rpmbuild --rebuild involves the following processes:

Installing the contents of the SRPM (the spec file and the source code) into the ~/rpmbuild/ directory.
Building an RPM by using the installed contents.
Removing the spec file and the source code.

You can retain the spec file and the source code after building either of the following ways:

When building the RPM, use the rpmbuild command with the --recompile option instead of the --rebuild option.

Install SRPMs for bello, pello, and cello:

rpm -Uvh ~/rpmbuild/SRPMS/bello-0.1-1.el8.src.rpm
rpm -Uvh ~/rpmbuild/SRPMS/pello-0.1.2-1.el8.src.rpm
rpm -Uvh ~/rpmbuild/SRPMS/cello-1.0-1.el8.src.rpm

$ rpm -Uvh ~/rpmbuild/SRPMS/bello-0.1-1.el8.src.rpm
Updating / installing…
   1:bello-0.1-1.el8               [100%]

$ rpm -Uvh ~/rpmbuild/SRPMS/pello-0.1.2-1.el8.src.rpm
Updating / installing…
…1:pello-0.1.2-1.el8              [100%]

$ rpm -Uvh ~/rpmbuild/SRPMS/cello-1.0-1.el8.src.rpm
Updating / installing…
…1:cello-1.0-1.el8            [100%]

Copy to Clipboard

Toggle word wrap

4.6.3. Building a binary RPM from a spec file
Link kopieren

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

Prerequisites

You have installed the rpmbuild utility on your system:
```
dnf install rpm-build
```
```
# dnf install rpm-build
```
Copy to Clipboard Toggle word wrap

Procedure

Navigate to the ~/rpmbuild/SPECS/ directive, which contains spec files:
```
cd ~/rpmbuild/SPECS/
```
```
$ cd ~/rpmbuild/SPECS/
```
Copy to Clipboard Toggle word wrap
Build the binary RPM from its spec:
```
rpmbuild -bb <spec_file>
```
```
$ rpmbuild -bb <spec_file>
```
Copy to Clipboard Toggle word wrap
For example, to build bello, pello, and cello binary RPMs from their spec files, enter:
```
rpmbuild -bb bello.spec
rpmbuild -bb pello.spec
rpmbuild -bb cello.spec
```
```
$ rpmbuild -bb bello.spec

$ rpmbuild -bb pello.spec

$ rpmbuild -bb cello.spec
```
Copy to Clipboard Toggle word wrap

4.7. Logging RPM activity to syslog
Link kopieren

You can log any RPM activity or transaction by using the System Logging protocol (syslog).

Prerequisites

The syslog plug-in is installed on the system:
```
dnf install rpm-plugin-syslog
```
```
# dnf install rpm-plugin-syslog
```
Copy to Clipboard Toggle word wrap
Note
The default location for the syslog messages is the /var/log/messages file. However, you can configure syslog to use another location to store the messages.

Procedure

Open the file that you configured to store the syslog messages.
Alternatively, if you use the default syslog configuration, open the /var/log/messages file.
Search for new lines including the [RPM] string.

4.8. Extracting RPM content
Link kopieren

In some cases, for example, if a package required by RPM is damaged, you might need to extract the content of the package. In such cases, if an RPM installation is still working despite the damage, you can use the rpm2archive utility to convert an .rpm file to a tar archive to use the content of the package.

Note

If the RPM installation is severely damaged, you can use the rpm2cpio utility to convert the RPM package file to a cpio archive.

Procedure

Convert the RPM file to the tar archive:
```
rpm2archive <filename>.rpm
```
```
$ rpm2archive <filename>.rpm
```
Copy to Clipboard Toggle word wrap
The resulting file has the .tgz suffix. For example, to create an archive from the bash package, enter:
```
rpm2archive bash-4.4.19-6.el8.x86_64.rpm
ls bash-4.4.19-6.el8.x86_64.rpm.tgz
```
```
$ rpm2archive bash-4.4.19-6.el8.x86_64.rpm
$ ls bash-4.4.19-6.el8.x86_64.rpm.tgz
bash-4.4.19-6.el8.x86_64.rpm.tgz
```
Copy to Clipboard Toggle word wrap

4.9. Signing RPM packages
Link kopieren

You can sign RPM packages to ensure no third party can alter their content by using either of the following software:

Sequoia PGP supports the OpenPGP standard. RPM also uses Sequoia PGP to verify software signatures.
GNU Privacy Guard (GnuPG) supports older OpenPGP standard versions, which makes GnuPG more compatible with RHEL 9 and earlier versions.

Warning

New algorithms and signatures might not be compatible with earlier RHEL versions.

4.9.1. Signing RPM packages with GnuPG
Link kopieren

You can sign RPM packages by using the GNU Privacy Guard (GnuPG) software.

4.9.1.1. Creating an OpenPGP key for signing packages with GnuPG
Link kopieren

To sign an RPM package by using the GNU Privacy Guard (GnuPG) software, you must create an OpenPGP key first.

Prerequisites

You have the rpm-sign and pinentry packages installed on your system.

Procedure

Generate an OpenPGP key pair:
```
gpg --gen-key
```
```
$ gpg --gen-key
```
Copy to Clipboard Toggle word wrap
Check the generated key pair:
```
gpg --list-keys
```
```
$ gpg --list-keys
```
Copy to Clipboard Toggle word wrap

Export the public key:

gpg --export -a '<public_key_name>' > RPM-GPG-KEY-pmanager

$ gpg --export -a '<public_key_name>' > RPM-GPG-KEY-pmanager

Copy to Clipboard

Toggle word wrap

4.9.1.2. Configuring RPM to sign a package with GnuPG
Link kopieren

To sign an RPM package by using the GNU Privacy Guard (GnuPG) software, you must configure RPM by specifying the %_gpg_name RPM macro.

Prerequisites

You created an OpenPGP key for GnuPG, For more information, see Creating an OpenPGP key for signing packages with GnuPG.

Procedure

Define the %_gpg_name macro in your $HOME/.rpmmacros directory:
```
%_gpg_name <key-ID>
```
```
%_gpg_name <key-ID>
```
Copy to Clipboard Toggle word wrap
A valid key ID value for GnuPG can be a key fingerprint, full name, or email address you provided when creating the key.

4.9.1.3. Adding a signature to an RPM package
Link kopieren

Packages are commonly built without signatures. You can add your signature before the package is released.

Prerequisites

You created an OpenPGP key for GnuPG. For more information, see Creating an OpenPGP key for signing packages with GnuPG.
You configured RPM for signing packages. For more information, see Configuring RPM to sign a package with GnuPG.
You have the rpm-sign package installed on your system.

Procedure

Add a signature to a package:
```
rpmsign --addsign <package-name>.rpm
```
```
$ rpmsign --addsign <package-name>.rpm
```
Copy to Clipboard Toggle word wrap

Verification

Import the exported OpenPGP public key into the RPM keyring:
```
rpmkeys --import RPM-GPG-KEY-pmanager
```
```
# rpmkeys --import RPM-GPG-KEY-pmanager
```
Copy to Clipboard Toggle word wrap
Display the key ID with GnuPG:
```
gpg --list-keys
```
```
$ gpg --list-keys
[...]
pub   rsa3072 2025-05-13 [SC] [expires: 2028-05-12]
      A8AF1C39AC67A1501450734F6DE8FC866DE0394D
[...]
```
Copy to Clipboard Toggle word wrap
The key ID is the 40-character string in the command output, for example, A8AF1C39AC67A1501450734F6DE8FC866DE0394D.

Verify that the RPM file has the corresponding signature:

rpm -Kv <package_name>.rpm

$ rpm -Kv <package_name>.rpm
<package_name>.rpm:
    Header V4 RSA/SHA256 Signature, key ID 6de0394d: OK
    Header SHA256 digest: OK
    Header SHA1 digest: OK
    Payload SHA256 digest: OK
    MD5 digest: OK

Copy to Clipboard

Toggle word wrap

The signature key ID matches the last part of the OpenPGP key ID.

4.9.2. Signing RPM packages with Sequoia PGP
Link kopieren

You can use Sequoia PGP to sign RPM packages and ensure no third party can alter their content.

4.9.2.1. Creating an OpenPGP key for signing packages with Sequoia PGP
Link kopieren

To sign packages by using the Sequoia PGP software, you must create an OpenPGP key first.

Procedure

Install the Sequoia PGP tools:
```
dnf install sequoia-sq
```
```
# dnf install sequoia-sq
```
Copy to Clipboard Toggle word wrap

Generate an OpenPGP key pair:

sq key generate --own-key --userid <key_name>

$ sq key generate --own-key --userid <key_name>

Copy to Clipboard

Toggle word wrap

Check the generated key pair:
```
sq key list
```
```
$ sq key list
```
Copy to Clipboard Toggle word wrap

Export the public key:

sq cert export --cert-userid '<key_name>' > RPM-PGP-KEY-pmanager

$ sq cert export --cert-userid '<key_name>' > RPM-PGP-KEY-pmanager

Copy to Clipboard

Toggle word wrap

4.9.2.2. Configuring RPM to sign a package with Sequoia PGP
Link kopieren

To sign an RPM package with the Sequoia PGP software, you must configure the RPM to use Sequoia PGP and specify the %_gpg_name macro.

Prerequisites

You have the rpm-sign package installed on your system.

Procedure

Copy the macros.rpmsign-sequoia file to the /etc/rpm directory:
```
cp /usr/share/doc/rpm/macros.rpmsign-sequoia /etc/rpm/
```
```
# cp /usr/share/doc/rpm/macros.rpmsign-sequoia /etc/rpm/
```
Copy to Clipboard Toggle word wrap
Get a valid OpenPGP key fingerprint value from the output of key listing:
```
sq cert list --cert-userid '<key_name>'
```
```
$ sq cert list --cert-userid '<key_name>'
 - 7E4B52101EB3DB08967A1E5EB595D12FDA65BA50
   - created 2025-05-13 10:33:29 UTC
   - will expire 2028-05-13T03:59:50Z

   - [    ✓    ] <key_name>
```
Copy to Clipboard Toggle word wrap
The key fingerprint is a 40-character string on the first line of the output, for example, 7E4B52101EB3DB08967A1E5EB595D12FDA65BA50.
Define the %_gpg_name macro in your $HOME/.rpmmacros file as follows:
```
%_gpg_name <key_fingerprint>
```
```
%_gpg_name <key_fingerprint>
```
Copy to Clipboard Toggle word wrap
Note that you can also use the full key ID instead of the fingerprint.
Note
Unlike GnuPG, Sequoia PGP accepts only the full key ID or fingerprint.

4.9.2.3. Adding a signature to an RPM package
Link kopieren

Packages are commonly built without signatures. You can add your signature before the package is released.

Prerequisites

You created an OpenPGP key. For more information, see Creating an OpenPGP key for signing packages with Sequoia PGP.
You configured RPM for signing packages. For more information, see Configuring RPM to sign a package with Sequoia PGP.
You have the rpm-sign package installed on your system.

Procedure

Add a signature to a package:
```
rpmsign --addsign <package-name>.rpm
```
```
$ rpmsign --addsign <package-name>.rpm
```
Copy to Clipboard Toggle word wrap

Verification

Import the exported OpenPGP public key into the RPM keyring:
```
rpmkeys --import RPM-PGP-KEY-pmanager
```
```
# rpmkeys --import RPM-PGP-KEY-pmanager
```
Copy to Clipboard Toggle word wrap

Display the key fingerprint of the signing key:

sq key list --cert-userid <key_name>

$ sq key list --cert-userid <key_name>
 - 7E4B52101EB3DB08967A1E5EB595D12FDA65BA50
   - user ID: <key_name> (authenticated)
   - created 2025-05-13 10:33:29 UTC
   - will expire 2028-05-13T03:59:50Z
   - usable for signing
   - @softkeys/7E4B52101EB3DB08967A1E5EB595D12FDA65BA50: available, unlocked

   - 78E56DD2E12E02CFEEA27F8B9FE57972D6BCEA6F
     - created 2025-05-13 10:33:29 UTC
     - will expire 2028-05-13T03:59:50Z
     - usable for decryption
     - @softkeys/7E4B52101EB3DB08967A1E5EB595D12FDA65BA50: available, unlocked
   - C06E45F8ABC3E59F44A9E811578DDDB66422E345
     - created 2025-05-13 10:33:29 UTC
     - will expire 2028-05-13T03:59:50Z
     - usable for signing
     - @softkeys/7E4B52101EB3DB08967A1E5EB595D12FDA65BA50: available, unlocked
   - E0BD231AB350AD6802D44C0A270E79FFC39C3B25
     - created 2025-05-13 10:33:29 UTC
     - will expire 2028-05-13T03:59:50Z
     - usable for signing
     - @softkeys/7E4B52101EB3DB08967A1E5EB595D12FDA65BA50: available, unlocked

Copy to Clipboard

Toggle word wrap

The key fingerprint is usually a signing subkey in the sq key list --cert-userid <key_name> command output, for example, E0BD231AB350AD6802D44C0A270E79FFC39C3B25.

Verify that the RPM file has the corresponding signature, for example:

rpm -Kv <package_name>.rpm

$ rpm -Kv <package_name>.rpm
<package_name>.rpm:
    Header V4 EdDSA/SHA512 Signature, key ID c39c3b25: OK
    Header SHA256 digest: OK
    Header SHA1 digest: OK
    Payload SHA256 digest: OK
    MD5 digest: OK

Copy to Clipboard

Toggle word wrap

The signature key ID matches the last part of the key fingerprint.

Dieser Inhalt ist in der von Ihnen ausgewählten Sprache nicht verfügbar.

4.1. Setting up RPM packaging workspaceLink kopierenLink in die Zwischenablage kopiert!

4.1.1. Configuring RPM packaging workspaceLink kopierenLink in die Zwischenablage kopiert!

4.1.2. RPM packaging workspace directoriesLink kopierenLink in die Zwischenablage kopiert!

4.2. About spec filesLink kopierenLink in die Zwischenablage kopiert!

4.2.1. Preamble itemsLink kopierenLink in die Zwischenablage kopiert!

4.2.2. Body itemsLink kopierenLink in die Zwischenablage kopiert!

4.2.3. Advanced itemsLink kopierenLink in die Zwischenablage kopiert!

4.3. BuildRootsLink kopierenLink in die Zwischenablage kopiert!

4.4. RPM macrosLink kopierenLink in die Zwischenablage kopiert!

4.5. Working with spec filesLink kopierenLink in die Zwischenablage kopiert!

4.5.1. Creating a new spec file for sample Bash, Python, and C programsLink kopierenLink in die Zwischenablage kopiert!

4.5.2. Modifying an original spec fileLink kopierenLink in die Zwischenablage kopiert!

4.5.3. An example spec file for a sample Bash programLink kopierenLink in die Zwischenablage kopiert!

4.5.4. An example spec file for a sample Python programLink kopierenLink in die Zwischenablage kopiert!

4.5.5. An example spec file for a sample C programLink kopierenLink in die Zwischenablage kopiert!

4.6. Building RPMsLink kopierenLink in die Zwischenablage kopiert!

4.6.1. Building a source RPMLink kopierenLink in die Zwischenablage kopiert!

4.6.2. Rebuilding a binary RPM from a source RPMLink kopierenLink in die Zwischenablage kopiert!

4.6.3. Building a binary RPM from a spec fileLink kopierenLink in die Zwischenablage kopiert!

4.7. Logging RPM activity to syslogLink kopierenLink in die Zwischenablage kopiert!

4.8. Extracting RPM contentLink kopierenLink in die Zwischenablage kopiert!

4.9. Signing RPM packagesLink kopierenLink in die Zwischenablage kopiert!

4.9.1. Signing RPM packages with GnuPGLink kopierenLink in die Zwischenablage kopiert!

4.9.1.1. Creating an OpenPGP key for signing packages with GnuPGLink kopierenLink in die Zwischenablage kopiert!

4.9.1.2. Configuring RPM to sign a package with GnuPGLink kopierenLink in die Zwischenablage kopiert!

4.9.1.3. Adding a signature to an RPM packageLink kopierenLink in die Zwischenablage kopiert!

4.9.2. Signing RPM packages with Sequoia PGPLink kopierenLink in die Zwischenablage kopiert!

4.9.2.1. Creating an OpenPGP key for signing packages with Sequoia PGPLink kopierenLink in die Zwischenablage kopiert!

4.9.2.2. Configuring RPM to sign a package with Sequoia PGPLink kopierenLink in die Zwischenablage kopiert!

4.9.2.3. Adding a signature to an RPM packageLink kopierenLink in die Zwischenablage kopiert!

Lernen

Testen, kaufen und verkaufen

Communitys

Über Red Hat Dokumentation

Mehr Inklusion in Open Source

Über Red Hat

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

4.1. Setting up RPM packaging workspace
Link kopieren

4.1.1. Configuring RPM packaging workspace
Link kopieren

4.1.2. RPM packaging workspace directories
Link kopieren

4.2. About spec files
Link kopieren

4.2.1. Preamble items
Link kopieren

4.2.2. Body items
Link kopieren

4.2.3. Advanced items
Link kopieren

4.3. BuildRoots
Link kopieren

4.4. RPM macros
Link kopieren

4.5. Working with spec files
Link kopieren

4.5.1. Creating a new spec file for sample Bash, Python, and C programs
Link kopieren

4.5.2. Modifying an original spec file
Link kopieren

4.5.3. An example spec file for a sample Bash program
Link kopieren

4.5.4. An example spec file for a sample Python program
Link kopieren

4.5.5. An example spec file for a sample C program
Link kopieren

4.6. Building RPMs
Link kopieren

4.6.1. Building a source RPM
Link kopieren

4.6.2. Rebuilding a binary RPM from a source RPM
Link kopieren

4.6.3. Building a binary RPM from a spec file
Link kopieren

4.7. Logging RPM activity to syslog
Link kopieren

4.8. Extracting RPM content
Link kopieren

4.9. Signing RPM packages
Link kopieren

4.9.1. Signing RPM packages with GnuPG
Link kopieren

4.9.1.1. Creating an OpenPGP key for signing packages with GnuPG
Link kopieren

4.9.1.2. Configuring RPM to sign a package with GnuPG
Link kopieren

4.9.1.3. Adding a signature to an RPM package
Link kopieren

4.9.2. Signing RPM packages with Sequoia PGP
Link kopieren

4.9.2.1. Creating an OpenPGP key for signing packages with Sequoia PGP
Link kopieren

4.9.2.2. Configuring RPM to sign a package with Sequoia PGP
Link kopieren

4.9.2.3. Adding a signature to an RPM package
Link kopieren