# 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} (even in comments,
# macros are expanded, 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.
# 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 farily 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
# 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 <john.smith@somecompany.yow>
# 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-<version>/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, by examining all executable programs and libraries being
# packaged are analyzed 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 software needed to build the
# 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 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.
# 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 override for 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.)
%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 begining with a percent symbol.
# The required Prep script creates the build root directory, unpackes 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
# 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:
%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 verisous 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 Jul 16 2010 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