rpm  5.4.10
spec
Go to the documentation of this file.
1 /*! \page specfile Spec file tags
2 
3 A few additions have been made to the spec file format.
4 
5 Name
6 
7 The Name tag contains the proper name of the package. Names must not
8 include whitespace and may include a hyphen '-' (unlike version and release
9 tags). Names should not include any numeric operators ('<', '>','=') as
10 future versions of rpm may need to reserve characters other than '-'.
11 
12 By default subpackages are named by prepending `MAIN-' 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
16 definition:
17 
18 \verbatim
19  %package -n newname
20 \endverbatim
21 
22 \subsection specfile_summary Summary: and Description: Tags
23 
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:
30 
31 \verbatim
32  Description: Screen drawing library
33  Name: screenlib
34  Version: 1.0
35 
36  %package devel
37  Description: Screen drawing library headers and static libs
38 \endverbatim
39 
40 might be changed to:
41 
42 \verbatim
43  Summary: Screen drawing library
44  Name: screenlib
45  Version: 1.0
46 
47  %description
48  The screen drawing library
49  is a handy development tool
50 
51  %package devel
52  Summary: Screen drawing library headers and static libs
53 
54  %description devel
55  This package contains all of the
56  headers and the static libraries for
57  screenlib.
58 
59  You'll only need this package if you
60  are doing development.
61 \endverbatim
62 
63 The description is free form text, but there are two things to note.
64 The first regards reformatting. 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.
68 
69 \subsection specfile_url URL: and Packager: Tags
70 
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
77 package contains).
78 
79 \subsection specfile_buildarchitectures BuildArchitectures: Tag
80 
81 This tag specifies the architecture 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.
86 
87 \subsection specfile_virtual Virtual File Attribute(s) in %files Section
88 
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).
92 
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.
99 
100 The %exclude subdirective permit to exclude files and directories
101 from inclusion in a package (i.e. "everything but"). Its primary use
102 is to simplify the writing the list of objects in %files when
103 using subpackage. Note that %exclude is different from a ipotetical
104 %ignore subattribute: it is always required that the file(s) excluded
105 but present in buildroot are referenced in some else subpackage %files
106 section: if this is not what you want then they should be eliminated
107 from the buildroot in %install.
108 
109 The %config(noreplace) indicates that the file in the package should
110 be installed with extension .rpmnew if there is already a modified file
111 with the same name on the installed machine.
112 
113 The virtual file attribute token %verify tells `-V/--verify' to ignore
114 certain features on files which may be modified by (say) a postinstall
115 script so that false problems are not displayed during package verification.
116 \verbatim
117  %verify(not size md5 mtime) %{prefix}/bin/javaswarm
118 \endverbatim
119 
120 \subsection specfile_globbing Shell Globbing of %files Section
121 
122 The usual rules for shell globbing apply. Most special characters can
123 be escaped by prefixing them with a '\'. Spaces are used to separate
124 file names and so must be escaped by enclosing the file name with quotes.
125 For example:
126 
127 \verbatim
128  /tmp/are\.you\|bob\?
129  /tmp/bob\'s\*htdocs\*
130  "/tmp/bob\'s htdocs"
131 \endverbatim
132 
133 Names containing "%%" will be rpm macro expanded into "%". When
134 trying to escape large number of file names, it is often best to
135 create a file with the complete list of escaped file names. This is
136 easiest to do with a shell script like this:
137 
138 \verbatim
139  rm -f $RPM_BUILD_DIR/filelist.rpm
140  echo '%defattr(-,root,root)' >> $RPM_BUILD_DIR/filelist.rpm
141  find $RPM_BUILD_ROOT/%{_prefix} -type f -print | \
142  sed "s!$RPM_BUILD_ROOT!!" | perl -pe 's/([?|*.\'"])/\\$1/g' \
143  >> $RPM_BUILD_DIR/filelist.rpm
144 
145  %files -f filelist.rpm
146 \endverbatim
147 
148 \subsection specfile_automatic Fine Adjustment of Automatic Dependencies
149 
150 Rpm currently supports separate "Autoreq:" and "Autoprov:" tags in a
151 spec file to independently control the running of find-requires and
152 find-provides. A common problem occurs when packaging a large third
153 party binary which has interfaces to other third party libraries you
154 do not own. RPM will require all the third party libraries be
155 installed on the target machine even though their intended use was
156 optional. To rectify the situation you may turn off requirements when
157 building the package by putting
158 
159 \verbatim
160  Autoreq: 0
161 \endverbatim
162 
163 in your spec file. Any and all requirements should be added manually using the
164 
165 \verbatim
166  Requires: depend1, ..., dependN
167 \endverbatim
168 
169 in this case.
170 
171 Similarly there is an Autoprov tag to turn off the automatic provision
172 generation and a Autoreqprov to turn off both the automatic provides and
173 the automatic requires generation.
174 
175 \subsection specfile_nosrc NoSource: Tag
176 
177 Files ending in .nosrc.rpm are generally source RPM packages whose spec
178 files have one or more NoSource: or NoPatch: directives in them. Both
179 directives use the named source or patch file to build the resulting
180 binary RPM package as usual, but they are not included in the source
181 RPM package.
182 
183 The original intent of this ability of RPM was to allow proprietary or
184 non-distributable software to be built using RPM, but to keep the
185 proprietary or non-distributable parts out of the resulting source RPM
186 package, so that they would not get distributed.
187 
188 They also have utility if you are building RPM packages for software
189 which is archived at a well-known location and does not require that
190 you distribute the source with the binary, for example, for an
191 organization's internal use, where storing large quantities of source
192 is not as meaningful.
193 
194 The end result of all this, though, is that you can't rebuild
195 ``no-source'' RPM packages using `rpm --rebuild' unless you also have
196 the sources or patches which are not included in the .nosrc.rpm.
197 
198 \subsection specfile_buildrequires BuildRequires: Tag
199 
200 Build dependencies are identical to install dependencies except:
201 
202 \verbatim
203  1) they are prefixed with build (e.g. BuildRequires: rather than Requires:)
204  2) they are resolved before building rather than before installing.
205 \endverbatim
206 
207 So, if you were to write a specfile for a package that requires egcs to build,
208 you would add
209 \verbatim
210  BuildRequires: egcs
211 \endverbatim
212 to your spec file.
213 
214 If your package was like dump and could not be built w/o a specific version of
215 the libraries to access an ext2 file system, you could express this as
216 \verbatim
217  BuildRequires: e2fsprofs-devel = 1.17-1
218 \endverbatim
219 
220 Finally, if your package used C++ and could not be built with gcc-2.7.2.1, you
221 can express this as
222 \verbatim
223  BuildConflicts: gcc <= 2.7.2.1
224 \endverbatim
225 
226 */