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 update 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.