3.9. Modifying an original SPEC file for creating RPMs

Procédure

1. Open the output template of the ~/rpmbuild/SPECS/<name>.spec file provided by the rpmdev-newspec utility:

2. Populate the first section of the SPEC file:

   The first section includes these directives that rpmdev-newspec grouped together:

   Name

   The Name was already specified as an argument to rpmdev-newspec.

   Version

   Set the Version to match the upstream release version of the source code.

   Release

   The Release is automatically set to 1%{?dist}, which is initially 1. Increment the initial value whenever updating the package without a change in the upstream release Version - such as when including a patch. Reset Release to 1 when a new upstream release happens.

   Summary

   The Summary is a short, one-line explanation of what this software is.

3. Populate the License, URL, and Source0 directives:

   The License field is the Software License associated with the source code from the upstream release. The exact format for how to label the License in your SPEC file will vary depending on which specific RPM based Linux distribution guidelines you are following.

   For example, you can use GPLv3+.

   The URL field provides URL to the upstream software website. For consistency, utilize the RPM macro variable of %{name}, and use https://example.com/%{name}.

   The Source0 field provides URL to the upstream software source code. It should link directly to the specific version of software that is being packaged. Note that the example URLs given in this documentation include hard-coded values that are possible subject to 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, you need to update only one field in the SPEC file.

4. Populate the BuildRequires, Requires and BuildArch directives:

   BuildRequires specifies build-time dependencies for the package.

   Requires specifies run-time dependencies for the package.

   This is a software written in an interpreted programming language with no natively compiled extensions. Hence, add the BuildArch directive with the noarch value. This tells RPM that this package does not need to be bound to the processor architecture on which it is built.

5. Populate the %description, %prep, %build, %install, %files, and %license directives:

   These directives can be thought of as section headings, because they are directives that can define multi-line, multi-instruction, or scripted tasks to occur.

   The %description is a longer, fuller description of the software than Summary, containing one or more paragraphs.

   The %prep section specifies how to prepare the build environment. This usually involves expansion of compressed archives of the source code, application of patches, and, potentially, parsing of information provided in the source code for use in a later portion of the SPEC file. In this section you can use the built-in %setup -q macro.

   The %build section specifies how to build the software.

   The %install section contains instructions for rpmbuild on how to install the software, once it has been built, into the BUILDROOT directory.

   This 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 the RPM macros without having to hardcode the paths.

   The %files section specifies the list of files provided by this RPM and their full path location on the end user’s system.

   Within this section, you can indicate the role of various files using built-in macros. This is useful for querying the package file manifest metadata using the rpm command. For example, to indicate that the LICENSE file is a software license file, use the %license macro.

6. The last section, %changelog, is a list of datestamped entries for each Version-Release of the package. They log packaging changes, not software changes. Examples of packaging changes: adding a patch, changing the build procedure in the %build section.

   Follow this format for the first line:

   Start with an * character followed by Day-of-Week Month Day Year Name Surname <email> - Version-Release

   Follow this format for the actual change entry:

   • Each change entry can contain multiple items, one for each change.
   • Each item starts on a new line.
   • Each item begins with a - character.