Annotated spec file

annotated-file.spec

#
# Author: Wayne Pollock  pollock@acm.org
#
#   See: http://wpollock.com/AUnix2/specFileWithComments.htm
#

# 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 names 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 http://fedoraproject.org/wiki/Packaging/RPMMacros for more info.
# See https://fedoraproject.org/wiki/Packaging:Guidelines#Tags_and_Sections
# For guidelines on packaging and spec file contents.
# Also see https://rpm-packaging-guide.github.io/#what-is-a-spec-file

# 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 major.minor.build 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, should not end in a period

License:        name of (and optionally the URL to) the license, e.g., "GPLv2"
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 deprecated - don't use
Packager:       John Q. Smith <john.smith@example.com> deprecated - don't use

# The optional Group tag is used to place this package in some yum group.
# The list of groups is found by running the command
#   rpm -qa --qf '%{group}\n' | sort -u  deprecated - don't use

Group:          Unspecified

# 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"), which
# you might use for shell or other scripts:

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.  However, there is optional
# Provides and Requires tags. Provides 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" (http://fedoraproject.org/wiki/Extras/MockTricks)
# 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".)

Source: ftp://example.com/foo/src/foo-1.2.3.tar.gz

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

# (See below for the modern replacement for Source and Patch tags.)

# 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 if vim created your spec:

#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.)

%description
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.

# Instead of the Source (and Patch) directive in the preamble section, you can
# (since RPM 4.15) list sources (and patches) in their own sections.
# The Patchlist is a list of patch files found in the SOURCES directory.
# These are source code patches and will be applied in the
# order listed, before building the software.  These no longer need to be URLs:

%sourcelist
foo-1.2.3.tar.gz

%patchlist
someniftypatch-1.16.1.patch

# 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):

%prep
%setup -q
%patch              Omit if no patches, of course

# 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):

%build
%configure
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):

%install
rm -rf $RPM_BUILD_ROOT
make install DESTDIR=$RPM_BUILD_ROOT

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

%clean
rm -rf $RPM_BUILD_ROOT

# 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:

%files

# 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"):

%defattr(0755,root,root,-)

# Next you list the files.  To install one with non-default attributes,
# use the "attr" tag as shown below.
/usr/bin/foo
/usr/lib/libfoo.so

# 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 and how many files can be listed
# in one line:

%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:

%changelog
 * Fri Jun 24 2016 Wayne Pollock <wpollock@example.com>
- Downloaded version 1.4, applied patches
* Tue May 08 2001 Peter Tosh <tosh@reggae.com> 1.3-1
- updated to 1.3 

 
Send comments and questions to pollock@acm.org
Last updated by Wayne Pollock on 11/18/2019 05:37:58. 	Valid HTML 4.01!   Valid CSS!   Website accessibility rating WCAG 1.0 AAA Approved by Cynthia Says   Website accessibility rating Section 508 approved by Cynthia Says