The spec file is the center of the entire RPM package creation process. It acts like the Makefile file during program compilation.
1. Spec file Parameters
The spec file contains the required information for creating an RPM package, including which files are part of the package and which directory they are installed in. This file is generally divided into the following sections:
(1) Preamle (preface)
The content displayed when the preface contains information about the user request package. It can contain the function description, software version, copyright information, and the package Group of the package. Summary is a line of description about the software package. Name is the base Name of the software package. Version is the Version number of the software, and Release is the Version number of the RPM, if an error in the spec file is fixed and the new RPM of the same version of the software is released, the release number should be added. License should provide some License terms (such as "GPL", "Commercial", "Ware ware"), Group identification software type. Programs that try to help people manage RPMs usually list RPMs by group. You can see a list of GROUPS used by Red Hat in the usr/share/doc/rpm-4.0.4/GROUPS file (assuming your installed RPM version is 4.0.4 ). However, you can also use other group names. Source0, Source1, etc. name these source files (usually tar.gz files ). % {Name} and % {version} Are RPM macros which are extended to the rpm names and versions defined in the header.
Note that do not include any paths in the Source statement. By default, RPM searches for files in/usr/src/redhat/SOURCES. Copy or link your source files to the file. (To make spec files portable as much as possible, avoid embedding them in the hypothetical path on your own development machine. Other developers can instruct RPM to search for source files in other directories without modifying your spec files .)
The following part starts with the % description line. You should provide more description of the software here, so that anyone can view it when querying your software package using rpm-qi. You can explain what the software package is doing, describe any warning or additional configuration instructions, and so on.
(2) Prep Section
The Prep section is used for actual packaging preparation, which is indicated by the Section prefix % prep. In general, the main task of this section is to check whether the tag syntax is correct, delete the old software source program, and decode the tar file containing the source program. If a patch file is included, apply the patch file to the unwrapped source code. It generally contains two Commands: % setup and % patch. % Setup is used to unbind the software source code package. Execute % patch to add the patch file to the Undo source program.
% Setup
-N newdir --------- unpack the compressed software source program under the newdir directory.
-C --------------- create a directory before unlocking the source program.
-B num ------------ extract the num source program when multiple source programs are included.
-T ---------------- do not use the default decompression operation.
For example:
% Setup-T-B 0
/* Unlock the first source program file. */
% Setup-c-n newdir
/* Create the directory newdir and unbind the source program under the directory. */
% Patch
% PatchN ------- here N is a number, indicating that the nth patch file is used, equivalent to % patch-P N
-P0 ----------- specify the first patch file and-p1 specify the second patch file. -S ------------ no information is displayed when the patch is used.
-B name ------- Add name to the source file before adding the patch file. If this parameter is specified, the default source file is added to. orig.
-T ------------ delete all output files generated during patching.
(3) Build Section
This section is mainly used to compile the source code. It is represented by the Section prefix % build. This section is generally composed of multiple make commands.
(4) Install Section
This section is mainly used to complete the commands that must be executed to install the software. It is indicated by the Section prefix % install. This section is generally composed of the make install command, but sometimes it also contains commands such as cp, mv, and install.
This section also specifies the script that runs when the package is installed on the user-installed system. Such a script is called the installation (uninstallation) script. It can specify the shell program segments that must be run by the system before, after, before, and after the package is installed. The verification script to verify whether a package has been successfully installed can also be specified in this section on the user-installed system.
(5) Clean Section
The content described in this section indicates that after creating a package, the script under this section is automatically executed to perform additional cleanup, which is indicated by the Section prefix % clean. Generally, this section uses the rm-rf $ RPM_BUILD_ROOT command and does not need to be specified.
(6) file list
This section specifies the list of files that constitute the package. It is represented by the Section prefix % files. In addition, it also contains a series of macro control file attributes and configuration information after installation.
% Files lists the files that should be bundled into RPM and can be set with permission and other information optional. In % files, you can use % defattr to define the default permission, owner, and Group. % defattr (-, root, root) will install all files Owned by the root user, use any permission they have when RPM binds them from the build system.
You can use % attr (permissions, user, group) to overwrite the owner and permission of an individual file. You can use one line in % files to include multiple files. You can add % doc or % config to the row to mark the file. % Doc tells RPM that this is a document file, so if you use -- excludedocs when installing the software package, this file will not be installed. You can also list file names without paths in % doc. RPM searches for these files in the build directory and includes them in the RPM file, install them to/usr/share/doc/% {name}-% {version }. It is a good idea to include files such as README and ChangeLog in the form of % doc.
% Config tells RPM that this is a configuration file. During the upgrade, the RPM will try to avoid overwriting the configuration you have carefully modified with the default configuration file packaged by the RPM.
Note: If a directory name is listed under % files, RPM will include all files in the directory. This is usually not what you want, especially for directories such as/bin.
(7) change log
This section mainly describes the software development records, which are expressed by the Section prefix % changlog. The content of this section is for developers to have a detailed understanding of the software development process, which is very good for package maintenance.
2. Spec file examples and explanations
Name: ao_redpacket (CPM Name) Version: 1 (CPM Version) Release: 5 (RPM Version) License: Commercial (authorized) Group: commodity (software type) Summary: the main AO module of commodity on basic platform (description) Vendor: Tencent (company) Packager: timmyye (publisher) Prefix:/usr/local (Prefix path) Provides: ao_redpacket (provided) requires: platform. framework public_scripts (required) Buildroot:/data/htdocs/rpm.paipaioa.com/rpm/data_32/rpm_build/commodity/ao_redpacket_1/build_directory (compilation path) % description (description) the main AO module of commodity on basic platform % files (installed file attributes and configuration information) % defattr (-, appadmin, users) (default permission, owner, and Group) % config/usr/local/c2csvc/svc/ao_redpacket/etc/* % dir/usr/local/c2csvc/svc/ao_redpacket % dir/usr/local/c2csvc/svc/ao_redpacket /etc/usr/local/c2csvc/svc/ao_redpacket/bin/usr/local/c2csvc/svc/ao_redpacket/no_itil/usr/local/c2csvc/svc/ao_redpacket/so/usr /local/c2csvc/so/ao_redpacket.so/data/applog/ao_redpacket/usr/local/c2csvc/svc/ao_redpacket/restart_itilid % pre