1
/*! \page specfile Spec file tags
3
A few additions have been made to the spec file format.
7
The Name tag contains the proper name of the package. Names must not
8
include whitespace and may include a hyphan '-' (unlike version and release
9
tags). Names should not include any numeric operators ('<', '>','=') as
10
future versions of rpm may need to reserve charcters other than '-'.
12
By default subpackages are named by prepending `<main package>-' to
13
the subpackages name(s). If you wish to change the name of a
14
subpackage (most commonly this is to change the '-' to '.'), then you
15
must specify the full name with the -n argument in the %package
22
\subsection specfile_summary Summary: and Description: Tags
24
The Summary: tag should be use to give a short (50 char or so) summary
25
of the package. Most package's Description: line should be changed to
26
a Summary: line. The Description: tag is still supported but should
27
be changed to a "%description" entry similar to %package and %files.
28
At some point in the future support will be removed for "Description:".
29
As an example, this spec file fragment:
32
Description: Screen drawing library
37
Description: Screen drawing library headers and static libs
43
Summary: Screen drawing library
48
The screen drawing library
49
is a handy development tool
52
Summary: Screen drawing library headers and static libs
55
This package contains all of the
56
headers and the static libraries for
59
You'll only need this package if you
60
are doing development.
63
The description is free form text, but there are two things to note.
64
The first regards reformating. Lines that begin with white space
65
are considered "pre-formatted" and will be left alone. Adjacent
66
lines without leading whitespace are considered a single paragraph
67
and may be subject to formatting by glint or another RPM tool.
69
\subsection specfile_url URL: and Packager: Tags
71
Two new tags are "URL:" and "Packager:". "URL:" is a place to put a
72
URL for more information and/or documentation on the software
73
contained in the package. Some future RPM package tool may make use
74
of this. The Packager: tag is meant to contain the name and email
75
address of the person who "maintains" the RPM package (which may be
76
different from the person who actually maintains the program the
79
\subsection specfile_buildarchitectures BuildArchitectures: Tag
81
This tag specifies the arctecture which the resulting binary package
82
will run on. Typically this is a CPU architecture like sparc,
83
i386. The string 'noarch' is reserved for specifying that the
84
resulting binary package is platform independent. Typical platform
85
independent packages are html, perl, python, java, and ps packages.
87
\subsection specfile_virtual Virtual File Attribute(s) in %files Section
89
A %ghost tag on a file indicates that this file is not to be included
90
in the package. It is typically used when the attributes of the file
91
are important while the contents is not (e.g. a log file).
93
The %config(missingok) indicates that the file need not exist on the
94
installed machine. The %config(missingok) is frequently used for files
95
like /etc/rc.d/rc2.d/S55named where the (non-)existence of the symlink
96
is part of the configuration in %post, and the file may need to be
97
removed when this package is removed. This file is not required to
98
exist at either install or uninstall time.
100
The %config(noreplace) indicates that the file in the package should
101
be installed with extension .rpmnew if there is already a modified file
102
with the same name on the installed machine.
104
The virtual file attribute token %verify tells `-V/--verify' to ignore
105
certain features on files which may be modified by (say) a postinstall
106
script so that false problems are not displayed during package verification.
108
%verify(not size md5 mtime) %{prefix}/bin/javaswarm
111
\subsection specfile_globbing Shell Gobbing of %files Section
113
The usual rules for shell globbing apply. Most special characters can
114
be escaped by prefixing them with a '\'. Spaces are used to separate
115
file names and so must be escaped by enclsing the file name with quotes.
120
/tmp/bob\'s\*htdocs\*
124
Names containing "%%" will be rpm macro expanded into "%". When
125
trying to escape large number of file names, it is often best to
126
create a file with the complete list of escaped file names. This is
127
easiest to do with a shell script like this:
130
rm -f $RPM_BUILD_DIR/filelist.rpm
131
echo '%defattr(-,root,root)' >> $RPM_BUILD_DIR/filelist.rpm
132
find $RPM_BUILD_ROOT/%{_prefix} -type f -print | \
133
sed "s!$RPM_BUILD_ROOT!!" | perl -pe 's/([?|*.\'"])/\\$1/g' \
134
>> $RPM_BUILD_DIR/filelist.rpm
136
%files -f filelist.rpm
139
\subsection specfile_automatic Fine Adjustment of Automatic Dependencies
141
Rpm currently supports separate "Autoreq:" and "Autoprov:" tags in a
142
spec file to independently control the running of find-requires and
143
find-provides. A common problem occurs when packaging a large third
144
party binary which has interfaces to other third party libraries you
145
do not own. RPM will require all the third party libraries be
146
installed on the target machine even though their intended use was
147
optional. To rectify the situation you may turn off requirements when
148
building the package by putting
154
in your spec file. Any and all requirements should be added manually using the
157
Requires: depend1, ..., dependN
162
Similarly there is an Autoprov tag to turn off the automatic provision
163
generation and a Autoreqprov to turn off both the automatic provides and
164
the automatic requires generation.
166
\subsection specfile_nosrc NoSource: Tag
168
Files ending in .nosrc.rpm are generally source RPM packages whose spec
169
files have one or more NoSource: or NoPatch: directives in them. Both
170
directives use the named source or patch file to build the resulting
171
binary RPM package as usual, but they are not included in the source
174
The original intent of this ability of RPM was to allow proprietary or
175
non-distributable software to be built using RPM, but to keep the
176
proprietary or non-distributable parts out of the resulting source RPM
177
package, so that they would not get distributed.
179
They also have utility if you are building RPM packages for software
180
which is archived at a well-known location and does not require that
181
you distribute the source with the binary, for example, for an
182
organization's internal use, where storing large quantities of source
183
is not as meaningful.
185
The end result of all this, though, is that you can't rebuild
186
``no-source'' RPM packages using `rpm --rebuild' unless you also have
187
the sources or patches which are not included in the .nosrc.rpm.
189
\subsection specfile_buildrequires BuildRequires: Tag
191
Build dependencies are identical to install dependencies except:
194
1) they are prefixed with build (e.g. BuildRequires: rather than Requires:)
195
2) they are resolved before building rather than before installing.
198
So, if you were to write a specfile for a package that requires egcs to build,
205
If your package was like dump and could not be built w/o a specific vesion of
206
the libraries to access an ext2 file system, you could express this as
208
BuildRequires: e2fsprofs-devel = 1.17-1
211
Finally, if your package used C++ and could not be built with gcc-2.7.2.1, you
214
BuildConflicts: gcc <= 2.7.2.1
added
removed
doc/manual/spec
