Product SiteDocumentation Site

⁠A.5. Spec File Preamble

This section include a list with descriptions of some of the more frequently used directives in spec files.
Name: name
The Name: tag defines the (base) name of the package. This name must follow the Fedora Package Naming Guidelines. Also, this name should match the spec file name. In many cases, the name will be in all lower case. For example: 
​Name: eject
Elsewhere in the spec file, you can refer to the name using the macro %{name}. That way, if the name changes, the new name will be used by those other locations.
Version: version
The Version tag defines the upstream version number. If the version is non-numeric (that is it contains tags that are not numbers or digits), you may need to include the additional non-numeric characters in the Release tag. If upstream uses full dates to distinguish versions, consider using version numbers of the form yy.mm[.dd] (so a 2008-05-01 release becomes 8.05). See Fedora Package Naming Guidelines for more information. An example of the Version tag: 
​Version: 2.1.5
Elsewhere in the spec file, refer to the tag value as %{version}. That way, if the tag value changes, the new value will be used by those other locations.
Release: release
The Release tag defines the value of the package's version. The initial release will typically be defined as 1%{?dist}. After the initial release, increment the number every time a new package is released for the same version of software. If a new version of the packaged software is released, the Version tag should be changed to reflect the new software version, and the Release tag should be reset to 1. See Fedora Package Naming Guidelines for more information. Refer to the Fedora Dist Tag Guidelines for a description of the dist tag, which is not required but can be useful. An example of the Release tag: 
​Release: 11%{dist}
Elsewhere in the spec file, refer to the tag value as %{release}. That way, if the tag value changes, the new value will be used by those other locations.
Summary: summary
The Summary tag defines a brief, one-line summary of the package. Do not use a period at the end of the summary. For example: 
​Summary: A program that ejects removable media using software control
Group: group
The Group tag defines a package group, which the package is a part of. The tag must define a previously existing group, for example Applications/Engineering. To display a complete list of existing groups, run the following command: 
less /usr/share/doc/rpm-*/GROUPS
If you create a package-doc sub-package with documentation, use the group Documentation. An example of the Group tag: 
​Group: System Environment/Base

The Group tag is deprecated

RPM in Fedora 18 does not require the presence of the Group tag in the spec file. If the tag is defined, it will be ignored. The package groups of the yum application are used on a Fedora 18 system as the relevant source of information on which group is the package a part of.
License: license
The License tag defines the license of the packaged software. Use a standard abbreviation, for example GPLv2+. The definition of the license should be specific; for example do not use GPL or GPLv2 when the license is in fact GPL version 2 or greater, that is GPLv2+. You can list multiple licenses in the tag by combining them with words and and or, for example GPLv2 and BSD. Refer to the Fedora Licensing Document and the Licensing Guidelines for more information on this topic.
Do not use the tag Copyright in place of the License tag. An example of the License tag: 
​License: GPL
URL: URL
The URL tag defines the URL with more information about the program, for example the project website. This tag does not define where the original source code came from, use the the tag Source for that purpose. An example of the URL tag: 
​URL: http://www.pobox.com/~tranter
Source0: URL
The Source tag defines a URL for the compressed archive containing the (original) unmodified source code, as upstream released it. The tag Source is the same as the tag Source0. Because a full URL should be provided with this tag, its basename can be then used when looking in the SOURCES/ directory. If possible, add %{name} and %{version} to the URL.
The tag Source and the tag URL are used for different purposes. Typically, they are both URLs, but the URL tag points to the project website, while the Source tag points to the actual file containing the source code.
When downloading the source code, consider using a client that preserves the upstream timestamps, such as wget. For example: 
wget -N URL
If you are using curl, run the following command: 
curl -R URL
If there is more than one source, name them Source1, Source2, and so on. If you are adding whole new files in addition to the unmodified sources, you can list each of them as sources as well, but list them after the unmodified sources. Remember to include a copy of each of these sources in any source package you create. For information on exceptions to this rule, such as when using revision control system, upstream using prohibited code, and so on, refer to the Fedora Source URL Guidelines. An example of the Source tag: 
​Source1: eject.pam
Patch0: file_name
The Patch0: tag defines the name of the first patch that you will apply to the source code. If you need to patch the files after they have been uncompressed, edit the files, save their differences as a patch file in the ~/rpmbuild/SOURCES/ directory. Patches should make only one logical change, so it is likely to have multiple patch files. If there is more than one source, name them Patch1, Patch2, and so on. An example of the Patch1 tag: 
​Patch1: eject-2.1.1-verbose.patch
BuildArch: architecture
The BuildArch tag is used to define the build architecture of the package. If you are packaging files that are architecture-independent, for example shell scripts, data files, and so on, use BuildArch: noarch. In this case, the architecture for the binary RPM will be noarch. An example of the BuildArch tag: 
​BuildArch: noarch
ExcludeArch: architecture
The ExcludeArch tag defines any excluded build architecture. If the package does not successfully compile, build or work on an architecture, then the architecture should be defined in the ExcludeArch tag. An example of the ExcludeArch tag: 
​ExcludeArch: i386
BuildRoot: build root
The BuildRoot defines the location of the files installed during the %install process, which happens after the %build compilation process. In a typical situation, leave this line alone: under the usual Fedora 18 setup, a macro that will create a new special subdirectory in the /var/tmp/ directory will be used. Newer versions of RPM ignore this value, and instead place the build root in %{_topdir}/BUILDROOT/. An example of the BuildRoot tag: 
​BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root

The BuildRoot tag is deprecated

RPM in Fedora 18 does not require the presence of the BuildRoot tag in the spec file. If the tag is defined, it will be ignored. The provided buildroot will automatically be cleaned before commands in %install are called.
BuildRequires: requirements
The BuildRequires tag defines a comma-separated list of packages required for building (or compiling) the software. These are not automatically determined, so you must include every package needed to build the software.
There are a few packages that are so common in builds that you do not need to mention them, such as gcc. Refer to the Fedora Packaging Guidelines for a complete list of the packages you may omit.
You can use more than one BuildRequires tag, in which case all BuildRequires tags they are all required for building. If necessary, you can also specify a minimum version of the package, for example: 
​ocaml >= 3.08
Try to specify only the minimal set of packages necessary to properly build the package, since each one will slow down a mock-based build. An example of the BuildRequires tag: 
​BuildRequires: gettext
Requires: requirements
The Requires tag defines a comma-separate list of packages that are required when the software is installed. Remember that the list of packages for the Requires tag and the BuildRequires tag are independent: a package may be in one list but not the other, or it can be in both. The dependencies of binary packages are in many cases automatically detected by pmbuild, so it is often the case that you do not need to specify the Requires tag at all. But if you want to highlight some specific packages as being required, or require a package that RPM cannot detect should be required, then add it to the Requires tag. An example of the Requires tag: 
​Requires: gettext
%description description text
The %description directive defines a longer, multiline description of the package. All lines must be 80 characters long or less. Blank lines are assumed to separate paragraphs. Remember that some graphical user interface installation programs will reformat paragraphs. Lines that start with whitespace, such as a space or tab, will be treated as preformatted text and displayed as is, normally with a fixed-width font. An example of the %description directive: 
​%description
​The eject program allows the user to eject removable media (typically
​CD-ROMs, floppy disks or Iomega Jaz or Zip disks) using software
​control. Eject can also control some multi-disk CD changers and even
​some devices' auto-eject features.
​
​Install eject if you'd like to eject removable media using software
​control.
%prep
The %prep directive defines script commands to prepare the software before the start of the building process. In a typical situation, the definition is similar to %setup -q. For example, if the source file unpacks into name, the definition is %setup -q -n name. An example of the %prep directive: 
​%prep
​%setup -q -n %{name}
​%patch1 -p1 -b .verbose
%build
The %build directive defines script commands to build (compile) the software, that is, to get it ready for installing. An example of the %build directive: 
​%build
​%configure
​make
%check
The %check directive defines script commands to self-test the program. The self-tests are run after %build and before %install, so the %check directive should be placed accordingly between the directives mentioned above. Usually, the %check directive contains the make test or make check commands. These commands are separated from the %build directive so that users can skip the self-test process, if they desire. 
​%check
​make check
%install
The %install directive defines script commands to install the software. The script commands copy the build files from the build directory %{_builddir} (usually a subdirectory of the directory ~/rpmbuild/BUILD/) into the build root directory %{buildroot} (usually a subdirectory of the directory /var/tmp/). An example of the%install directive: 
​%install
​rm -rf %{buildroot}
​
​make DESTDIR=%{buildroot} install
​
​install -m 755 -d %{buildroot}/%{_sysconfdir}/pam.d
​install -m 644 %{SOURCE1} %{buildroot}/%{_sysconfdir}/pam.d/%{name}
​install -m 755 -d %{buildroot}/%{_sysconfdir}/security/console.apps/
​echo "FALLBACK=true" > %{buildroot}/%{_sysconfdir}/security/console.apps/%{name}
​
​install -m 755 -d %{buildroot}/%{_sbindir}
​pushd %{buildroot}/%{_bindir}
​mv eject ../sbin
​ln -s consolehelper eject
​popd
%clean
The %clean directive defines instructions on how to clean out the build root. For example: 
​%clean
​rm -rf %{buildroot}

The %clean directive is deprecated

RPM in Fedora 18 does not require the presence of the %clean directive in the spec file. If the tag is defined, it will be ignored.
%files
The %files directive contains a list of files in the package to be installed. For example: 
​%files -f %{name}.lang
%changelog
The %changelog directive defines changes in the package. For example: 
​%changelog
​* Wed Apr 02 2008 John Due <jdoe at example.com> 2.1.5-11
​- Added check if device is hotpluggable
​- Resolves #438610