Packaging Tutorial 1: banner

Version contains the version number of the packaged software.

Release numbers specfile updates, package rebuilds and other work within Fedora. The value used here, %autorelease, is part of rpmautospec, which is recommended for Fedora packages. It ties Release to package’s Git history. As we do not have a Git repository, %autorelease will evaluate to the default value of 1.

Often, Summary can be copied from the upstream README. The first letter should be uppercase to avoid rpmlint complaints.

License describes the license of the resulting binary package using a SPDX license identifier. It must follow Fedora’s licensing guidelines. In practice, determining the correct value often means inspecting the license notifications in individual source files. Upstream developers may also need to be asked for clarifications or corrections. In this tutorial, we just take the upstream’s word that the license is the GNU Public License, version 2.

URL points to upstream project’s website, which in this case is the GitHub repo’s page.

Source defines the upstream sources used when building the package. Usually, as in this case, it is a url pointing to a tarball released by the upstream, but it can also be a local file. There can be multiple Source tags if needed.

%description can often be copied from upstream README.

%prep contains a shell script for preparing the sources for building. It is often just the single macro %autosetup, which, in this case, simply extracts the source.

%build contains a shell script for the required build steps, such as compiling sources to binaries. Since banner’s buildsystem is Autotools, building it involves running configure and make. Macros %configure and %make_build invoke these commands using Fedora’s compilation flags and other configuration.

%install contains a shell script to copy the results from %build into an initially empty build root directory. As banner is using Autotools, macro %make_install is used.

%files lists the content of the resulting package. Mostly, the files come from the build root created in the %install, but documentation and license files can also be added directly from the sources. This section is left empty for now, to be filled later.

The %changelog documents the changes in each new package version and release. Changelog data can be displayed by rpm --query --changelog PACKAGE_NAME, which can be useful, for instance, to find out if specific bug and security patches are included. Its value,%autochangelog, also comes from rpmautospec. It populates the changelog from Git commit messages. As we do not have a Git repository, the changelog will be empty.

Lines which are not needed can be commented out with the hash #.

You can find more information in the RPM Reference Manual’s section Spec file format.

This is the executable binary program. /usr/bin, like many other system directories, have a default rpm macro defined. The macros should always be used when available, so the executable is listed in %files as follows:

The Packaging Guidelines have a dedicated section for Manpages. Following its instructions, manpages are list as follows:

At this point, mockbuild completes successfully, but there are still more files that we should add to the package.

Every package must install its license, tagged with %license directive. In banner’s case, as well as for many other projects, the license file is located at the source tarball’s top level, and perhaps not copied to the buildroot during installation at all. Regardless, it can be installed to the standard license directory by using a relative path:

Often, package sources contain documentation that could be useful for the end users as well. These can be installed and marked as documentation with the %doc directive. Similarly to %license, relative paths can be used to include files directly from the source tarball rather than from the buildroot:

List the files contained in the package:

You can see that all the files listed in the specfile %files section are included. Also, under /usr/lib/.build-id, there is an automatically generated file. It is actually a symlink, mapping a build id to the banner binary for debugging purposes.

List the package’s runtime dependencies with the following command:

To check which packages in Fedora repositories provide these dependencies, you can use dnf repoquery:

You will see that the only dependency of banner is glibc, which provides symbols in libc.so.6 as well as rtld(GNU_HASH).

The rpmlib requires are special. These specify various rpm features used in the rpm package itself, constraining the version of rpm that can be used to install the package.

Conversely, to check what capabilities the package provides, you can do:

The provides of this package are very simple. It simply provides its own name, in plain and architecture specific forms.

As a final check, the package can be installed and ran:

To clean up your system, undo the installation: