Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
The Spec File
When you build packages, you use spec files to provide the information and scripts that automate the package-building process itself, and the information and scripts that are bundled as part of the package. This second set of scripts is used on the user's system when the package is installed.
These two sets of information are intermingled in the spec file, without any distinction between them other than their names. However, it is important to remember which items are used on your system during the package-building process and which items are used on the end user's system during package use.
The spec file for a package is located in the SPECS directory and needs to have a filename consisting of the name of the package, the version number, and the extension .spec. For example, the name of the spec file for ed is ed-0.2.spec. For spec files that are used to produce multiple packages (such as –devel or –static packages), the base package name is used for the filename.
A spec file includes two different kinds of entries: one-line fields and multiline sections. The one-line fields are placed at the top of the file in the header, and the sections follow. Most sections in the spec file contain Bourne shell scripts that run either during the package-building process or on the end user's system during package installation or removal. However, the %Description section is just a series of text lines that describe the package. Listing 1 shows the spec file for the ed package on Caldera OpenLinux, which is used for the examples in this chapter. This spec file has been simplified to shorten it for inclusion in this article. If you have installed the ed source RPM, you can look at the unedited version at /usr/src/distribution/SPECS/ed-0.2.spec.
Listing 1 The Spec File for ed (Simplified)
Summary: GNU Line Editor Name: ed Version: 0.2 Release: 5 Group: Textprocessing/Editor Copyright: GPL Packager: rwp@lst.de (Roger Pook) Icon: ed.gif # URL: No WWW site found Source0: ftp://prep.ai.mit.edu/pub/gnu/ed-0.2.tar.gz # Patch: - optional - # Provides: - optional - # Requires: - optional - # Conflicts: - optional - BuildRoot: /tmp/ed-0.2 %Description ed is a line-oriented text editor. It is used to create, display, modify, and otherwise manipulate text files. red is a restricted ed: it can edit only files in the current directory and cannot execute shell commands. %Prep %setup %Build ./configure-prefix=/usr-exec-prefix=/ make CFLAGS="$RPM_OPT_FLAGS" LDFLAGS=-s %Install DESTDIR=$RPM_BUILD_ROOT; export DESTDIR make CFLAGS="$RPM_OPT_FLAGS" LDFLAGS=-s install prefix=$DESTDIR/usr exec_prefix=$DESTDIR/ gzip -9fn $DESTDIR/usr/info/ed.info %Post lisa-info install ed-section "Miscellaneous:"-entry "* ed:(ed). The GNU line-oriented text editor." %PreUn lisa-info remove ed $1 %Files %doc NEWS POSIX README THANKS /bin/ed /bin/red /usr/info/ed.info.gz /usr/man/man1/ed.1.gz /usr/man/man1/red.1.gz
Fields in the Spec File
Fields are indicated with the field name followed by a colon. A pound sign (#) indicates a comment in the spec file, either in the header or in any of the sections.
Most of the fields are pieces of information that are just put into the package when it is built. However, some are used during the actual build process.
Informational Fields
The following are descriptions of the informational fields most commonly used in a spec file:
-
Summary—A one-line description of the package.
-
Name—The name of the package.
-
Version—The version of the software in the package.
-
Release—The release number of the package. This is what you modify if you make changes to the package (that is, when the original version of the software has not changed).
-
Group—The group is a multipart (usually two-part) string used by package-management utilities to organize the packages into a hierarchy. The parts of the group are separated by a slash. For example, the ed package is in the Textprocessing/Editor group. A list of all the groups is available in the GROUPS file with your RPM documentation (usually /usr/doc/rpm-3.0.5, if you have it installed.)
-
Copyright—This indicates the copyright holder and the license that the software uses. Common values for the license are BSD, distributable, GPL, artistic, public domain, MIT, freeware, and shareware.
-
Packager—This provides the name and email address of the person who built this package. In the case of packages that come with your distribution, this field is often used to track who internally maintains the package. Please don't contact this person to get support for the software in the package. If you have questions about the software provided by a package, visit the site at which the software originated, or use other normal support channels.
-
Provides—This lists the items that the package provides. The package automatically provides its own name and all the files that it contains (including shared libraries and interpreters), so these do not need to be explicitly listed.
-
Requires—This lists the items that the package requires. If programs in the package require shared libraries or interpreters, rpm detects this automatically, and these items do not need to be explicitly listed.
-
Conflicts—This lists conflicts that the package has. For instance, if this were a mail engine, it might conflict with sendmail because there can usually be only one mail engine on a machine. This information is used by RPM to prevent two conflicting packages from being installed on the same machine.
-
Obsoletes—This lists packages that are obsoleted by this package. This is a more specific version of the Conflicts field.
-
BuildRoot—This option instructs RPM to place files in a temporary directory during the install step. This is very useful when building packages for a distribution. For more information, see the section "BuildRoot," later in this article.
-
%Description—This is a multiline description of the package. Actually, this is a section and not a field, but it fits better here because it is purely informational and is not used during package building.
Fields Used During Package Building
The following fields are used during the build process:
-
Icon—This is the graphics file (often GIF) that contains an icon for this package (used by graphical package-management tools).
-
Source#—This is a URL for the source files for the software. The filename part is used by the build process, and the rest of the URL is for informational purposes. Note that Source is the same as Source0 (the 0 is optional).
-
Patch#—These entries denote the filenames of the patch files used during the build process. Patch is the same as Patch0.
Sections
Sections in the spec file begin with a section identifier and continue until the next section identifier. The section identifiers start with a percent sign.
Unfortunately, rpm uses a percent sign to indicate both section identifiers and directives in the %Prep and %Files sections, which can be confusing. Some packagers capitalize the first letter of section identifiers and leave directive names in all lowercase to distinguish the two in their spec files, but this is not universal.
Most sections in the spec file contain shell scripts that perform the actions required for that stage of the build process.
Sections Used During the Build Process
The following sections are used during the build process:
-
%Prep—This section contains a shell script to extract the source files and apply the patches. It is used during the prep stage.
-
%Build—This contains a shell script to build (compile) the software. It is used during the build stage.
-
%Install—This contains a shell script to install the software. This is used during the install stage. (You can probably see a pattern emerging here!)
-
%Files—This section contains a listing of the files and directories in the package.
-
%Clean—This optional section contains a shell script to clean up after a package build.
-
%Changelog—This contains changelog information about the SPEC file itself.
Sections for Package Scripts
The following scripts are not used at build time; they are inserted into the package and are used by the package manager on the end user's system when the package is installed, removed, or verified.
-
%Pre/%Post—Scripts to run on the end user's system before and after installing the package files.
-
%Preun/%Postun—Scripts to run on the end user's system before and after removing the package files.
-
%Triggerin/%Triggerun—Scripts to run when a specific package is installed and uninstalled. For example, these could be used by a mail client to add sendmail support whenever sendmail is installed.
-
%Triggerpostun—Script to run after a specific package is uninstalled (versus before the package is uninstalled, in the case of %Triggerun).
-
%Verify—Script to run on the end user's system to verify the package files. If empty, the default verification mechanism of RPM is used.
Helper Packages
It is common to have helper packages defined in a spec file. For example, if the package mypackage also has a mypackage-devel package, both will be described in the same spec file. Generally, the only thing that differs in the helper packages is the list of files and the information fields. To define the information fields for a helper package, the spec file uses the %package directive followed by the fields. After that, sections use the package's name to differentiate—for example:
%package devel Summary: Development files for applications which will manipulate RPM packages. Group: Development/Libraries %ifos linux Requires: python >= 1.5.1 %endif %description devel This package contains the RPM C library and header files. These development files will simplify the process of writing programs that manipulate RPM packages and databases, and are intended to make it easier to create graphical package managers or any other tools that need an intimate knowledge of RPM packages to function.