Annotated spec file

# A spec file contains a number of sections, in a specific order,
# each of which contains tags and/or data.  Comments and blank lines
# are ignored.  Tags are of the form "name:value".  The name of
# tags are not case-sensitive; white-space around the colon is optional.

# The values can include macros of the form %%{name} (macros are expanded
# even in comments, so the percent must be escaped by using "%%";
# macros only use a single percent symbol).  If you wish to use a
# macro only if it is defined, use %%{?name}.  Many macros are predefined,
# and additional ones can be defined in ~/.rpmmacros or by using the
# %%global (preferred) or %%define tags.
# See for more info.

# The required name tag should match the name of the software.
# The name (on the right of the colon) cannot contain any whitespace.

Name:           foo

# The required version tag should match the developer's version number,
# usually this uses the scheme but doesn't have to.
# Note the value of this tag can't contain any dashes.

Version:        1.2.3

# The required release is typically a single number provided by the packager.
# It often indicates what patch level (of the packager) has been applied.

Release:        1%{?dist}

# The optional Epoch tag provides an ordering for the version
# numbers (replacing the deprecated Serial tag). Use this tag
# if RPM cannot figure out the ordering of which release comes
# after another, just by examining version numbers.  (This can happen
# because the version and release numbers are unrelated.)  Hopefully
# you won't need this tag:

Epoch:          1

# Next is a bunch of required tags that are fairly obvious in meaning:

Summary:        required one-line description of package

License:        name of (and optionally the URL to) the license, e.g., "GPL v2"
URL:            URL_to_package_home
Distribution:   Linux_or_product_distribution_this_package_is_for

# These are optional.  Vendor is set automatically by the build system,
# and Packager should be set in your ~/.rpmmacros file instead:
Vendor:         name_of_vendor
Packager:       John Q. Smith <>

# The optional Group tag is used to place this package in some yum group.
# The list of groups is found in /usr/share/doc/rpm/GROUPS.

Group:          Applications/Text

# The optional Icon tag says what icon to display on a GUI desktop for
# this RPM file.

Icon:           filename-without-extension
# or:
#Icon:    /full/path/to/icon/filename-including-extension
# (The first way is preferred as it allows for theming.)

# The optional BuildArch (and the related ExcludeArch) is for architecture
# dependent RPMs.  The following says this is independent ("noarch"):

BuildArch:     noarch

# Normally RPM determines the software provided and required when building
# a package; it examines all executable programs and libraries being
# packaged, analyzes them to determine their shared library requirements as
# well as interpreters required (such as "bash"), and any required modules
# for all Perl scripts and modules being packaged.  Also, the soname of
# each shared library being packaged is automatically added to the
# package's list of "provides" information.
# The optional Provides tag is used to specify a "virtual package" that the
# packaged software makes available when it is installed.  Normally,
# this tag would be used when different packages provide equivalent services.
# For example:
#  Provides:   mta

# The optional Requires tag refer to the name of another package, or
# to a virtual package.  Version comparisons may also be included by
# following the package name with <, >, =, <=, or >=, and
# a version (optionally with release and epoch).  For example:

Requires:       mcrypt >= 2.6.8

# RPM does not determine automatically other packages needed to build this
# package, so you need to specify all packages in a comma separated list
# for the BuildRequires tag.  (The most commonly used stuff, gcc, bash, awk,
# etc is assumed and you don't need to list that.  To find missing required
# packages, install and use "mock" (
# or "mach".

# The "conflicts" tag is used to specify what packages cannot be installed
# if the current package is to operate properly, using the same syntax as
# for the Requires tag ("epoch:version-release").

# The optional "prefix" tag is used when a relocatable package is to be built.
# It specifies the leading part of the absolute pathnames listed elsewhere,
# that can be replaced with the "--prefex=" rpm option.  If this tag is
# not present then the package is not relocatable.  You can have multiple
# prefix tag, such as for /etc, /usr/share/man, etc.

Prefix: /usr/bin

# (Note:  In Fedora, the use of relocatable packages is strongly discouraged.
# It is difficult to make work properly, impossible to use from yum, and
# not generally necessary if other packaging guidelines are followed.)

# The required Source tag indicates the name of the source file used to build
# the RPM.  It is usually a URL, but only the name following the final
# slash is used; that file is under the SOURCES directory.
# A spec file may contain more than one source tag, each with a number
# such as "source1", "source2", ...  ("source" is the same as "source0".)


# Similar to the source tag, the optional Patch tag(s) list(s) any patch files
# that should be applied to the source files.

# RPM needs a location to put the compiled files before they can
# be bundled into an RPM package.  This is called the "build root".
# The vim spec file template includes and overrides the default
# location, but I don't recommend using anything but the default, so
# you should remove or comment out this optional line:

#BuildRoot:      %%(mktemp -ud %%{_tmppath}/%%{name}-%%{version}-%%{release}-XXXXXX)

# You should also include a longer description section,
# marked by %%description on a line by itself, and ending with
# the next section marker.  (Don't have lines in the description
# that look like tags or section names!  As with comments, double up
# any percent symbols.)

In the description section, blank lines indicate paragraphs.
Lines that start with a space are not wrapped/filled.

# Following the (global) directives are the script sections.  Each
# starts with a keyword beginning with a percent symbol.

# The required Prep script creates the build root directory, unpacks the source
# into that directory, applies any patches to the source, and does any
# other prep steps needed (usually none, but this might include creating
# users, directories, or even a database).  Usually you just need to do
# standard stuff, and the "%%setup" (and "%%patch") built-in macros do that
# (The "-q" means show minimal output):

%setup -q

# The required Build script includes the steps needed to build the software.
# Usually this is just "./configure" (you can use the built-in "%%configure"
# macro for that, which will also setup various environment variables used
# by the Gnu configure script), possibly with configure options, followed
# by "make" (including any make options, such as "-j2"; in the command
# below a macro is used to include that option if the macro is defined):

make %{?_smp_mflags}

# The required Install script first cleans up the build root and then
# installs the software there (so it can easily be bundled into the RPM
# we will create):


# Finally you need to define the script to run after the RPM has been
# built, to clean up any leftover files:


# You can define four optional additional scripts, that get copied into
# the RPM.  These are the pre- and post- install scripts, and the
# pre- and post- remove scripts.  You rarely need to add these, but
# the post script is the most often used: to run chkconfig and to start
# the new service, for example.  These should not be interactive:
# %%pre
# %%post
# %%preun
# %%postun

# The required files section defines all the files that go into the RPM.
# These should be absolute pathnames (but will be relative to the buildroot).
# This section contains some optional directives that can be used to
# describe the file's type or set owner/group/modes.  In addition to
# listing individual files you can use shell-style wild-cards (globs)
# and list whole directories:


# First set the defaults for all the files listed.  The four values are
# the file permissions, the owner, the group, and the directory permissions.
# Use a dash if you just want the default (determined by the install step,
# such as a chmod command done as part of the "make install"):


# Next you list the files.  To install one with non-default attributes,
# use the "attr" tag as shown below.

# You should list man pages and any package documentation files you
# want to install too.  But these should be marked as documentation
# files.  By default certain directories are assumed to be documentation
# so you could just list those files or directories (/usr/share/doc,
# /usr/share/man, and /usr/share/info).
# As a special case, file names (without a leading slash) that are
# in the build root, should normally not be installed in "/"!  If
# you list such a filename then RPM will install it into a default
# documentation directory, /usr/share/doc/<packagename>-<version>.
# Notice how two directives are used together:

%attr(0644,root,root) %doc /usr/share/man/man1/foo.1.gz
%attr(0644,root,root) %doc README NEWS LICENSE CREDITS

# Similar to the doc directive is the %%config directive.  This takes
# some options, to control the over-writing of existing config files:
#  %%config(noreplace) - don't over-write an existing file that was
#                        modifed from the original version (you get
#                        a whatever.rpmnew file instead).  Without the
#                        noreplace option, a changed file will be saved
#                        as whatever.rpmsave before the new file is writen.
#  %%config(missingok) - Use this for config files that don't exist
#                        (created later, possibly in the "post' script),
#                        but need to be removed when the package is.

%attr(0644,root,root) %config /etc/foo.conf

# Not shown here, but you can also use the "lang" tag to mark some file
# as needing installation only for that language:
#  %%lang(fr) %%{_datadir}/locale/fr/LC_MESSAGES/foo* 

# When the RPM package has had a significant change (used new version of
# the source, changed various options, etc.), you should add an entry to
# the RPM's change log (at the top).  This is done in the last optional
# section, and usually looks like the following:

 * Fri Jun 24 2016 Wayne Pollock <>
- Downloaded version 1.4, applied patches
* Tue May 08 2001 Peter Tosh <> 1.3-1
- updated to 1.3