head 1.1; branch 1.1.1; access ; symbols MAXIMUM_RPM_1_0:1.1.1.1 VENDOR:1.1.1; locks ; strict; comment @# @; 1.1 date 2001.08.28.12.07.10; author rse; state Exp; branches 1.1.1.1; next ; 1.1.1.1 date 2001.08.28.12.07.10; author rse; state Exp; branches ; next ; desc @@ 1.1 log @Initial revision @ text @ Concise Spec File Reference spec file contents of Comments spec file comments in Comments are a way to make RPM ignore a line in the spec file. To create a comment, enter an octothorp (#) at the start of the line. Any text following the comment character will be ignored by RPM: # This is the spec file for playmidi 2.3... Comments can be placed in any section of the spec file. See also: . The Preamble This section outlines the tags that comprise a spec file's preamble. Package Naming Tags This section outlines the tags that are used to name a package. The <command>Name:</command> Tag spec file tags in Name: Name: tag The Name: tag is used to define the name of the software being packaged. Name: cdplayer See also: . The <command>Version:</command> Tag spec file tags in Version: Version: tag The Version: tag defines the version of the software being packaged. Version: 1.2 See also: . The <command>Release:</command> Tag spec file tags in Release: Release: tag The Release: tag can be thought of as the package's version. Release: 5 See also: . Descriptive Tags <command>%description</command> Directive -- Describe the packages intended use. spec file tags in %description %description tag The %description tag is used to define an in-depth description of the packaged software. In the descriptive text, a space in the first column indicates that that line of text should be presented to user as-is, with no formatting done by RPM. Blank lines in the descriptive text denote paragraphs. %description It slices! It dices! It's a CD player app that can't be beat. By using the resonant frequency of the CD itself, it is able to simulate 20X oversampling. This leads to sound quality that cannot be equaled with more mundane software... The %description tag can be made specific to a particular subpackage by adding the subpackage name, and optionally, the option: %description bar %description -n bar The subpackage name and usage of the option must match those defined with the %package directive. See also: . The <command>Summary:</command> Tag spec file tags in Summary: Summary: tag The Summary: tag is used to define a one-line description of the packaged software. Summary: A CD player app that rocks! See also: . The <command>Copyright:</command> Tag spec file tags in Copyright: Copyright: tag The Copyright: tag is used to define the copyright terms applicable to the software being packaged. Copyright: GPL See also: . The <command>Distribution:</command> Tag spec file tags in Distribution: Distribution: tag The Distribution: tag is used to define a group of packages, of which this package is a part. Distribution: Doors '95 See also: . The <command>Icon:</command> Tag spec file tags in Icon: Icon: tag The Icon: tag is used to name a file containing an icon representing the packaged software. The file may be in either GIF or XPM format, although XPM is preferred. In either case, the background of the icon should be transparent. Icon: foo.xpm See also: . The <command>Vendor:</command> Tag spec file tags in Vendor: Vendor: tag The Vendor: tag is used to define the name of the entity that is responsible for packaging the software. Vendor: White Socks Software, Inc. See also: . The <command>URL:</command> Tag spec file tags in URL: URL: tag The URL: tag is used to define a Uniform Resource Locator that can be used to obtain additional information about the packaged software. URL: http://www.gnomovision.com/cdplayer.html See also: . The <command>Group:</command> Tag spec file tags in Group: Group: tag The Group: tag is used to group packages together by the types of functionality they provide. Group: Applications/Editors See also: . The <command>Packager:</command> Tag spec file tags in Packager: Packager: tag The Packager: tag is used to hold the name and contact information for the person or persons who built the package. Packager: Fred Foonly <fred@@gnomovision.com> See also: . Dependency Tags The <command>Provides:</command> Tag spec file tags in Provides: Provides: tag The Provides: tag is used to specify a "virtual package" that the packaged software makes available when it is installed. Provides: module-info See also: . The <command>Requires:</command> Tag spec file tags in Requires: Requires: tag The Requires: tag is used to alert RPM to the fact that the package needs to have certain capabilities available in order to operate properly. Requires: playmidi A version may be specified, following the package specification. The following comparison operators may be placed between the package and version: <, >, =, >=, or <= Requires: playmidi >= 2.3 If the Requires: tag needs to perform a comparison against a serial numbered defined with the Serial: tag, then the proper format would be: Requires: playmidi =S 4 See also: . The <command>Serial:</command> Tag spec file tags in Serial: Serial: tag The Serial: tag is used to define a serial number for a package. This is only necessary if RPM is unable to determine the ordering of a package's version numbers. Serial: 4 See also: . The <command>Conflicts:</command> Tag spec file tags in Conflicts: Conflicts: tag The Conflicts: tag is used to alert RPM to the fact that the package is not compatible with other packages. Conflicts: playmidi A version may be specified, following the package specification. The following comparison operators may be placed between the package and version: <, >, =, >=, or <= Conflicts: playmidi >= 2.3 If the Conflicts: tag needs to perform a comparison against a serial numbered defined with the Serial: tag, then the proper format would be: Conflicts: playmidi =S 4 See also: . The <command>AutoReqProv:</command> Tag spec file tags in AutoReqProv: AutoReqProv: tag The AutoReqProv: tag is used to control the automatic dependency processing performed when the package is being built. To disable automatic dependency processing, add the following line: AutoReqProv: no (The number 0 may be used instead of no) Although RPM defaults to performing automatic dependency processing, the effect of the AutoReqProv: tag can be reversed by changing no to yes. (The number 1 may be used instead of yes) See also: . Architecture- and Operating System-Specific Tags The <command>ExcludeArch:</command> Tag spec file tags in ExcludeArch: ExcludeArch: tag The ExcludeArch: tag is used to direct RPM to ensure that the package does not attempt to build on the excluded architecture(s). ExcludeArch: sparc alpha See also: . The <command>ExclusiveArch:</command> Tag spec file tags in ExclusiveArch: ExclusiveArch: tag The ExclusiveArch: tag is used to direct RPM to ensure the package is only built on the specified architecture(s). ExclusiveArch: sparc alpha See also: . The <command>ExcludeOs:</command> Tag spec file tags in ExcludeOs: ExcludeOs: tag The ExcludeOs: tag is used to direct RPM to ensure that the package does not attempt to build on the excluded operating system(s). ExcludeOS: linux irix See also: . The <command>ExclusiveOs:</command> Tag spec file tags in ExclusiveOs: ExclusiveOs: tag The ExclusiveOs: tag is used to denote which operating system(s) should only be be permitted to build the package. ExclusiveOS: linux See also: . Directory-related Tags The <command>Prefix:</command> Tag spec file tags in Prefix: Prefix: tag The Prefix: tag is used to define part of the path RPM will use when installing the package's files. The prefix can be redefined by the user when the package is installed, thereby changing where the package is installed. Prefix: /opt See also: . The <command>BuildRoot:</command> Tag spec file tags in BuildRoot: BuildRoot: tag The BuildRoot: tag is used to define an alternate build root, where the software will be installed during the build process. BuildRoot: /tmp/cdplayer See also: . Source and Patch Tags The <command>Source:</command> Tag spec file tags in Source: Source: tag The Source: tag is used to define the filename of the sources to be packaged. When there is more than one Source: tag in a spec file, each one must be numbered so they are unique, starting with the number 0. When there is only one tag, it does not need to be numbered. By convention, the source filename is usually preceded by a URL pointing to the location of the original sources, but RPM does not require this. Source0: ftp://ftp.gnomovision.com/pub/cdplayer-1.0.tgz Source1: foo.tgz See also: . The <command>NoSource:</command> Tag spec file tags in NoSource: NoSource: tag The NoSource: tag is used to alert RPM to the fact that one or more source files should be excluded from the source package file. The tag is followed by one or more numbers. The numbers correspond to the numbers following the Source: tags that are to be excluded from packaging. NoSource: 0, 3 See also: . The <command>Patch:</command> Tag Patch: tag The Patch: tag is used to define the name of a patch file to be applied to the package's sources. When there is more than one Patch: tag in a spec file, each one must be numbered so they are unique, starting with the number 0. When there is only one tag, it does not need to be numbered. Patch: cdp-0.33-fsstnd.patch See also: . The <command>NoPatch:</command> Tag NoPatch: tag The NoPatch: tag is used to alert RPM to the fact that one or more patch files should be excluded from the source package file. The tag is followed by one or more numbers. The numbers correspond to the numbers following the Patch: tags that are to be excluded from packaging. NoPatch: 2 3 See also: . Scriptlets This section lists the various scriptlets found in a spec file. Build Scriptlets Every build scriptlet has the following environment variables defined: RPM_SOURCE_DIR RPM_BUILD_DIR RPM_DOC_DIR RPM_OPT_FLAGS RPM_ARCH RPM_OS RPM_ROOT_DIR RPM_BUILD_ROOT RPM_PACKAGE_NAME RPM_PACKAGE_VERSION RPM_PACKAGE_RELEASE For more information on these environment variables, and build scriptlets in general, please see . <command>%prep</command> Directive -- Unpack archives and apply patches. spec file scriptlets %prep %prep scriptlet The %prep scriptlet is executed first during a build, The scriptlet normally prepares the contents of a source package for building, usually by unpacking archives and applying patches. The scriptlet can contain any valid sh commands. %prep See also: . <command>%build</command> Directive -- Configure and compile components to be packaged. spec file scriptlets %build %build scriptlet The %build scriptlet is the second scriptlet executed during a build, immediately after %prep. The scriptlet normally builds the components to be included in a binary package, usually by configuring and compiling source code from the previously unpacked and patched archives. The scriptlet can contain any valid sh commands. %build See also: . <command>%install</command> Directive -- Install components to be packaged. spec file scriptlets %install %install scriptlet The %install scriptlet is the third scriptlet executed during a build, immediately after %build. The scriptlet normally installs components to be included in a binary package, usually by copying files from the build directory tree to an install directory tree. The scriptlet can contain any valid sh commands. %install See also: . <command>%clean</command> Directive -- Remove build components. spec file scriptlets %clean %clean scriptlet The %clean scriptlet is executed at the end of a build. The scriptlet cleans up files produced during a build, usually by removing the install directory tree. The scriptlet can contain any valid sh commands. %clean See also: . Install/Erase Scriptlets These scriptlets are executed whenever the package is installed or erased. Each scriptlet can contain any valid sh commands. Note: Each of the following scriptlet can be made specific to a particular subpackage by adding the subpackage name, and optionally, the option: %post bar %preun -n bar The subpackage name and usage of the option must match those defined with the %package directive. Each scriptlet has the following environment variable defined: RPM_INSTALL_PREFIX For more information on this environment variable please see . The <command>%pre</command> Script spec file scriptlets %pre %pre scriptlet The %pre scriptlet executes just before the package is to be installed. %pre See also: . The <command>%post</command> Script spec file scriptlets %post %post scriptlet The %post scriptlet executes just after the package is to be installed. %post See also: . The <command>%preun</command> Script spec file scriptlets %preun %preun scriptlet The %preun scriptlet executes just before the package is to be erased. %preun See also: . <command>%postun</command> Directive spec file scriptlets %postun %postun scriptlet The %postun scriptlet executes just after the package is to be erased. %postun See also: . <command>%verifyscript</command> Directive This section describes the verification script. The <command>%verifyscript</command> Script spec file scriptlets %verifyscript %verifyscript scriptlet The %verifyscript scriptlet executes whenever the package is verified using RPM's option. The scriptlet can contain any valid sh commands. See also: . Macros This section describes the various macros used by RPM. The <command>%setup</command> Macro spec file macros in %setup %setup macro The %setup macro is used to unpack the original sources in preparation for the build. It is used in the %prep script: %prep %setup See also: . The <option>-n <replaceable><name></replaceable></option> Option spec file macros in %setup, options to %setup macro options to The option is used to set the name of the software's build directory. This is necessary only when the source archive unpacks into a directory named other than <name>- <version>. %setup -n cd-player See also: . The <option>-c</option> Option The option is used to direct %setup to create the top-level build directory before unpacking the sources. %setup -c See also: . The <option>-D</option> Option The option is used to direct %setup to not delete the build directory prior to unpacking the sources. This option is used when more than one source archive is to be unpacked into the build directory, normally with the or options. %setup -D -T -b 3 See also: . The <option>-T</option> Option The option is used to direct %setup to not perform the default unpacking of the source archive specified by the first Source: tag. It is used with the or options. %setup -D -T -a 1 See also: . The <option>-b <replaceable><n></replaceable></option> Option The option is used to direct %setup to unpack the source archive specified on the nth Source: tag line before changing directory into the build directory. %setup -D -T -b 2 See also: . The <option>-a <replaceable><n></replaceable></option> Option The option is used to direct %setup to unpack the source archive specified on the nth Source: tag line after changing directory into the build directory. %setup -D -T -a 5 See also: . The <command>%patch</command> Macro spec file macros in %patch %patch macro The %patch macro, as its name implies, is used to apply patches to the unpacked sources. With no additional options specified, it will apply the patch file specified by the Patch: (or Patch0:) tag. %patch When there is more than one Patch: tag line in a spec file, they can be specified by appending the number of the Patch: tag to the %patch macro name itself. %patch2 See also: . The <option>-P <replaceable><n></replaceable></option> Option spec file macros in %patch, options to %patch macro options to The option is another method of applying a specific patch. The number from the Patch: tag follows the option. The following %patch macros both apply the patch specified on the Patch2: tag line: %patch -P 2 %patch2 See also: . The <option>-p<replaceable><#></replaceable></option> Option The option is sent directly to the patch command. It is followed by a number which specifies the number of leading slashes (and the directories in between) to strip from any filenames present in the patch file. %patch -p2 See also: . The <option>-b <replaceable><name></replaceable></option> Option When the patch command is used to apply a patch, unmodified copies of the files patched are renamed to end with the extension .orig. The option is used to change the extension used by patch. %patch -b .fsstnd See also: . The <command>%patch -E</command> Option The option is sent directly to the patch command. It is used to direct patch to remove any empty files after the patches have been applied. See also: . The <command>%files</command> List spec file %files list in The %files list indicates which files on the build system are to be packaged. The list consists of one file per line. If a directory is specified, by default all files and subdirectories will be packaged. %files /etc/foo.conf /sbin/foo /usr/bin/foocmd The %files list can be made specific to a particular subpackage by adding the subpackage name, and optionally, the option: %files bar %files -n bar The subpackage name and usage of the option must match those defined with the %package directive. The %files list can also use the contents of a file as the list of files to be packaged. This is done by using the option, which is then followed by a filename: %files -f files.list See also: . Directives For the <command>%files</command> list This section lists the various directived used in the %files lists. File-related Directives This section lists those directives that are related to files. The <command>%doc</command> Directive spec file directives in %doc %doc directive The %doc directive flags the filename(s) that follow as being documentation. %doc README See also: . The <command>%config</command> Directive spec file directives in %config %config directive The %config directive is used to flag the specified file as being a configuration file. %config /etc/fstab See also: . The <command>%attr</command> Directive spec file directives in %attr %attr directive The %attr directive is used to permit RPM to directly control a file's permissions and ownership. It is normally used when non-root users build packages. The %attr directive has the following format: %attr(<mode>, <user>, <group>) file The user and group identifiers must be non-numeric. Attributes that do not need to be set by %attr may be replaced with a dash: %attr(755, root, -) foo.bar See also: . The <command>%verify</command> Directive spec file directives in %verify %verify directive The %verify directive is used to control which of nine different file attributes are to be verified by RPM. The attributes are: owner — The file's owner. group — The file's group. mode — The file's mode. md5 — The file's MD5 checksum. size — The file's size. maj — The file's major number. min — The file's minor number. symlink — The file's symbolic link string. mtime — The file's modification time. If the keyword not precedes the list, every attribute except those listed will be verified. %verify(mode md5 size maj min symlink mtime) /dev/ttyS0 See also: . Directory-related Directives The <command>%docdir</command> Directive spec file directives in %docdir %docdir directive The %docdir directive is used to add the specified directory to RPM's internal list of directories containing documentation. When a directory is added to this list, every file packaged in this directory (and any subdirectories) will automatically be marked as documentation. See also: . The <command>%dir</command> Directive spec file directives in %dir %dir directive The %dir directive is used to direct RPM to package only the directory itself, regardless of what files may reside in the directory at the time the package is created. %dir /usr/blather See also: . <command>%package</command> Directive %package directive The %package directive is used to control the creation of subpackages. The subpackage name is derived from the first Name: tag in the spec file, followed by the name specified after the %package directive. Therefore, if the first Name: tag is: Name: foo and a subpackage is defined with the following %package directive: %package bar the subpackage name will be foo-bar. See also: . The <command>%package -n</command> Option spec file directives in %package, options to %package directive option The option is used to change how RPM derives the subpackage name. When the option is used, the name following the %package directive becomes the complete subpackage name. Therefore, if a subpackage is defined with the following %package directive: %package -n bar the subpackage name will be bar. See also: . Conditionals The %ifxxx conditionals are used to begin a section of the spec file that is specific to a particular architecture or operating system. They are followed by one or more architecture or operating system specifiers, each separated by commas or whitespace. Conditionals may be nested within other conditionals, provided that the inner conditional is completely enclosed by the outer conditional. The <command>%ifarch</command> Conditional spec file conditionals in %ifarch %ifarch conditional If the build system's architecture is specified, the part of the spec file following the %ifarch, but before a %else or %endif will be used during the build. %ifarch i386 sparc See also: . The <command>%ifnarch</command> Conditional spec file conditionals in %ifnarch %ifnarch conditional If the build system's architecture is specified, the part of the spec file following the %ifarch but before a %else or %endif will not be used during the build. %ifnarch i386 sparc See also: . The <command>%ifos</command> Conditional spec file conditionals in %ifos %ifos conditional If the build system is running one of the specified operating systems, the part of the spec file following the %ifos but before a %else or %endif will be used during the build. %ifos linux See also: . The <command>%ifnos</command> Conditional spec file conditionals in %ifnos %ifnos conditional If the build system is running one of the specified operating systems, the part of the spec file following the %ifnos but before a %else or %endif will not be used during the build. %ifnos linux See also: . The <command>%else</command> Conditional spec file conditionals in %else %else conditional The %else conditional is placed between a %if conditional of some persuasion, and an %endif. It is used to create two blocks of spec file statements, only one of which will be used in any given case. %ifarch alpha make RPM_OPT_FLAGS="$RPM_OPT_FLAGS -I ." %else make RPM_OPT_FLAGS="$RPM_OPT_FLAGS" %endif See also: . The <command>%endif</command> Conditional spec file conditionals in %endif %endif conditional An %endif is used to end a conditional block of spec file statements. The %endif is always needed after a conditional, otherwise, the build will fail. %ifarch i386 make INTELFLAG=-DINTEL %endif See also: . @ 1.1.1.1 log @Import book 'Maximum RPM' by Ed Bailey, version 1.0 @ text @@