This article is original, reprinted or any other method of use need to be authorized by the author!

Introduction to RPM

Software package manager on Linux system is used to track and manage the installed programs on the system, among which rpm,dpkg and so on are more famous. RPM is called RPM Package Manager (also known as Red Hat Package Manager in the early days). It was originally developed by Red Hat to implement software management on Red Hat Linux. Now, thanks to its powerful management functions, many distributions use RPM as a tool for package management, which makes RPM become a tool for package management. Actual industrial standards. Of course, RPM itself is also released by Red Hat based on open source agreements. Recently, RPM file formats have also been adopted as official standards by LSB (Linux Standards Base).

RPM was originally developed by Marc Ewing and Erik Troan of Red Hat. It has the following characteristics in managing software packages (i.e. its design objectives):

(1) ease of use

(2) Software package orientation (i.e. package-centric)

(3) Easy to upgrade

(4) Tracking dependencies between packages

(5) Easy to query

(6) Supporting multiple system architectures

(7) Use pure source code

The RPM package contains a set of labeled data (such as NAME:nginx) and the main body of the package. It is usually an archive compressed file containing one or more files and installation instructions for specifying the location, ownership/subordinate group, permission of each file. Label data is used to describe the necessary optional features of software packages, while the main body of software packages mainly refers to the files to be installed on the system. Further, RPM packages typically consist of four components: the leading markup area used to mark files in RPM format, digital signatures, label data (also known as header) and the body.

In order to facilitate the management of software packages, all the command formats of RPM packages follow a unified specification, which consists of four parts: name-version-release.architecture.rpm.

RPM is divided into two types: binary format and source code. RPM packages in binary format have been compiled and installed on specific platforms. They usually contain compiled programs, library files, configuration or help files, etc. Of course, there are also some RPM packages in binary format that are platform independent, that is, the platform part in their name is noarch's RPM packages. The RPM packages in source format are usually packaged to make commands, scripts, program source codes and program patches for binary RPM packages, which can be used for rapid production of RPM packages in binary format on specific platforms.

On the system, RPM databases are used to store information about all RPM packages installed into the current system, usually many files in the / var/lib/rpm / directory. These files can be used to query and verify installed RPM packages. They are usually:

[root@www.magedu.com ~]# ls -lh /var/lib/rpm/
total 35M
-rw-r--r-- 1 root root 4.8M Jan 15 14:09 Basenames
-rw-r--r-- 1 root root  12K Jan 15 14:08 Conflictname
-rw-r--r-- 1 root root    0 Jan 15 14:02 __db.000
-rw-r--r-- 1 root root  24K Jan 15 14:00 __db.001
-rw-r--r-- 1 root root 1.3M Jan 15 14:00 __db.002
-rw-r--r-- 1 root root 440K Jan 15 14:00 __db.003
-rw-r--r-- 1 root root 1.1M Jan 15 14:09 Dirnames
-rw-r--r-- 1 root root 5.1M Jan 15 14:09 Filemd5s
-rw-r--r-- 1 root root  12K Jan 15 14:09 Group
-rw-r--r-- 1 root root  16K Jan 15 14:09 Installtid
-rw-r--r-- 1 root root  40K Jan 15 14:09 Name
-rw-r--r-- 1 root root  24M Jan 15 14:09 Packages
-rw-r--r-- 1 root root 168K Jan 15 14:09 Providename
-rw-r--r-- 1 root root  76K Jan 15 14:09 Provideversion
-rw-r--r-- 1 root root  12K Feb  2  2012 Pubkeys
-rw-r--r-- 1 root root 232K Jan 15 14:09 Requirename
-rw-r--r-- 1 root root 156K Jan 15 14:09 Requireversion
-rw-r--r-- 1 root root  84K Jan 15 14:09 Sha1header
-rw-r--r-- 1 root root  44K Jan 15 14:09 Sigmd5
-rw-r--r-- 1 root root  12K Jan 15 14:02 Triggername

Among them, _db.001 file is the lock file used by RPM for package management. The remaining files are usually in Berkeley DB format. The most important one is Packages, which contains the first label information of all RPM packages installed in the current system. Other files, such as Name,Providename and Group, are usually used to improve access efficiency. Once damaged, they can be rebuilt using the RPM command - rebuild.

II. Brief Introduction to the Relevant Orders of RPM

RPM command: execute the basic commands of RPM package installation, upgrade, uninstall, check, query and other related management work.

rpmbuild command: command to make RPM packages.

rpm2cpio command: A command that expands an RPM package into CPIO format. The result of the expansion is usually transmitted to the CPIO command through a "pipeline" for further processing. Such as:

# rpm2cpio  ngnix-1.0.14-1.el5.i386.rpm | cpio -t
# rpm2cpio  ngnix-1.0.14-1.el5.i386.rpm | cpio -id

3. Dependency of RPM Packets

Programs usually do not run completely independently, and they are always built on the basis of other functions, such as nginx, which needs to use network-related library files, SSL library files, I/O-related library files on the system, etc. These are manifested in RPM packages that provide different functions, which are the dependencies between packages.

Described in a RPM-specific way, each package provides a specific capability. In most cases, capabilities are represented by the name of a file or a package, but they can also be clearly defined for an RPM. The dependency of a particular RPM package is usually defined as its dependency on a certain "capability", which is saved to the RPM database when an RPM package is installed. When RPM is uninstalled, if its "capability" is dependent on other RPMs, the uninstall command generates an error message.

When defining the dependencies of RPM packages, it is usually possible to define the version information of RPM packages that they depend on in practice. In addition, when multiple packages may provide the same "capabilities", such as httpd and thttpd. When a "capability" exists on the system, RPM package conflicts will occur when the same capability package is installed on the system. At the same time, when a new version of RPM package provides an updated "capability" than its old version, it will lead to obsoletes.

The - Requirements option of the rpm command, together with the - q option, can be used to query the "capabilities" that a RPM package depends on, such as:

[root@www.magedu.com ~]# rpm -q --requires httpd
/bin/bash
/bin/mktemp
/bin/mv
/bin/rm
/bin/sh
/bin/sh
/bin/sh
/bin/sh
/bin/sh
/etc/mime.types
/sbin/chkconfig
/usr/bin/find
/usr/sbin/useradd
/usr/share/magic.mime
config(httpd) = 2.2.3-31.el5
gawk
initscripts >= 8.36
... ...
... ...

The -- provides option of the rpm command, together with the - q option, can be used to query the "capabilities" provided by an RPM package, such as:

[root@www.magedu.com ~]# rpm -q --provides httpd
config(httpd) = 2.2.3-31.el5
httpd-mmn = 20051115
mod_actions.so
mod_alias.so
mod_asis.so
mod_auth_basic.so
mod_auth_digest.so
... ...
... ...

The - conflicts option of the rpm command, together with the - q option, can be used to query "capabilities" that conflict with an RPM package, such as:

[root@www.magedu.com ~]# rpm -q --conflicts httpd

pcre < 4.0

The - whatrequires option of the rpm command, together with the - q option, can be used to query other "capabilities" that depend on the "capabilities" provided by an RPM package, such as:

[root@www.magedu.com ~]# rpm -q --whatrequires initscripts
portmap-4.0-65.2.2.1
foomatic-3.0.2-38.3.el5
kbd-1.12-21.el5
dhclient-3.0.5-21.el5
... ...
... ...

IV. Transactions in RPM

A transaction is a set of operations considered as a whole. All operations can be revoked by "rollback", and after "rollback", the system can return to its original state. If the transaction is successfully executed, the system will be transferred from the old state to the new state. Once any operation in the process of transaction execution fails, the system will be in an inconsistent state. At this time, transaction "rollback" is needed to ensure the consistency of the system state.

In RPM systems, when a package is installed or deleted, a transaction is initiated and a transaction ID is given to all RPM packages being operated on. Then, based on the same transaction ID, various operations such as transaction rollback can be implemented. At present, RPM system only supports rollback of software upgrade operation. One of the greatest benefits of transactions for RPM systems is that in an RPM command, if a package installation error occurs, the entire command will not proceed, and there will be no installation of some packages.

The method of viewing the transaction ID of a package installation is as follows:

[root@www.magedu.com ~]# rpm -q --qf "%-20{NAME} %-20{INSTALLTID}\n" httpd

httpd                1332925671          

If you want to see which packages are installed in an ID transaction, you can use the following methods:

[root@www.magedu.com ~]# rpm -q --tid 1332925671

httpd-2.2.3-31.el5

5.1. Overview of Production Process

We first look at the composition of internal files by expanding a list of files in the completed rpm package:

[root@www.magedu.com ~]# rpm2cpio nginx-1.0.14-1.i386.rpm | cpio -t
./etc/logrotate.d/nginx
./etc/nginx
./etc/nginx/fastcgi.conf
./etc/nginx/fastcgi.conf.default
./etc/nginx/fastcgi_params
./etc/nginx/fastcgi_params.default
./etc/nginx/koi-utf
./etc/nginx/koi-win
./etc/nginx/mime.types
./etc/nginx/mime.types.default
./etc/nginx/nginx.conf
./etc/nginx/nginx.conf.default
./etc/nginx/scgi_params
./etc/nginx/scgi_params.default
./etc/nginx/uwsgi_params
./etc/nginx/uwsgi_params.default
./etc/nginx/win-utf
./etc/rc.d/init.d/nginx
./usr/html/50x.html
./usr/html/index.html
./usr/sbin/nginx
./usr/share/doc/nginx-1.0.14
./usr/share/doc/nginx-1.0.14/CHANGES
./usr/share/doc/nginx-1.0.14/LICENSE
./usr/share/doc/nginx-1.0.14/README

It can be seen that the binary rpm is actually a collection of files to be installed on the Linux system. The path in the list above is the location where the binary rpm is installed on the system. Therefore, the first step in making RPM packages is to determine the files contained in them and the source of these files, such as, for an application, whether they are pre-compiled files and other files, or compiled and generated in the process of making RPM packages, etc. When all this is done, you also need to create a specs file to make this RPM package to indicate how the production process works.

Then you can test the production and generate the final rpm package. Generally speaking, the above process can be divided into the following steps:

(1) Determine the RPM package to be generated, including all the contents of the package and the type of RPM package to be generated after the production is completed;
(2) Collect relevant source programs, related documents and patch files for packaging;
(3) If an application is to be packaged, it is necessary to read its README, INSTALL and other related documents beforehand, and test that it meets the production needs and can normally complete the compilation and installation process.
(4) If this RPM package can be used to upgrade the old version of the program, it also needs to plan the upgrade related matters, such as how to handle the configuration files of the old version of the program, whether to execute some processing scripts, etc.
(5) Determine the dependencies of the RPM package, including the "capabilities" that are dependent on when it is made and the "capabilities" that are dependent on when it is installed.
(6) Producing RPM packages;

The process of producing RPM package is simply to provide a "workshop" for the production process, that is, a directory, which needs to contain the following sub-directories:
BUILD - The working directory for compiling related source packages;
RPMS - The location where the generated binary RPM package is stored;
SOURCES - the storage location of source files and other auxiliary files of the program;
SPCES - the storage location of spec files;
SRPMS - The location where the generated RPM package in src format is stored;

When "workshop" is ready to stop, put the source code and auxiliary files in the corresponding SOURCES directory, and create a spec file in the SPECS directory, you can use the rpmbuild command to start the production process. Since there are no restrictions on the rights of root users, improper commands in RPM production process may damage the system, so root users must not be used to perform the production process. Remember!

5.2. rpm macro and its definition method

Commands such as RPM and rpmbuild depend on a predefined working environment when they work. The environment-related information is defined by the RPM macro and can be obtained by using the command's showrc option. For example, on Red Hat Linux systems, the default workshops for RPM packages are / usr/src/redhat directories, which are actually defined by the RPM macro _topdir. We can get the definition of "workshops" location by macro_topdir in the Showrc option of rpmbuild. In the RPM working environment where everything is set by default, because _topdir also refers to other macros, we can use the following commands to get relevant information:

[mage@www.magedu.com ~]$ rpmbuild --showrc |grep  _usr
-14: _defaultdocdir %{_usr}/share/doc
-14: _topdir %{_usrsrc}/redhat
-14: _usr /usr
-14: _usrsrc %{_usr}/src

If you want to get information about macro_topdir itself, you can use the following commands:

[mage@www.magedu.com ~]$ rpmbuild --showrc |grep _topdir
-14: _builddir %{_topdir}/BUILD
-14: _rpmdir %{_topdir}/RPMS
-14: _sourcedir %{_topdir}/SOURCES
-14: _specdir %{_topdir}/SPECS
-14: _srcrpmdir %{_topdir}/SRPMS
-14: _topdir %{_usrsrc}/redhat

In fact, you can also use the rpm command to get the definition of an rpm macro directly:
[mage@www.magedu.com ~]$ rpm --eval  '%_topdir'
/usr/src/redhat

Above, _topdir is used to define the "workshop" directory when making RPM packages, which is defined as a "macro" that acts like variables in scripting. Define or refer to the value of a macro in the form of% {macro_name} or% macro_name. As can be seen from the above command execution results, the _topdir macro also determines its location by referring to the _usr and _usrsrc macros, i.e.%{usrsrc}/redhat path. When making RPM, the rpmbuild command takes the directory specified by _topdir as the top-level directory of its work, and finds BUILD,RPMS,SOURCES,SPRMS,SPECS and other directories as needed. Therefore, as long as the value is changed, the position of the "workshop" can be changed.

By default, these macros are defined by the relevant configuration files of rpm macros, which usually have more than one configuration file. The path information of the relevant files of the current system can be obtained by using the following commands:
[mage@www.magedu.com ~]$ rpmbuild --showrc | grep macrofiles
macrofiles         : /usr/lib/rpm/macros:/usr/lib/rpm/athlon-linux/macros:/usr/lib/rpm/redhat/macros:/etc/rpm/macros.*:/etc/rpm/macros:/etc/rpm/athlon-linux/macros:~/.rpmmacros

The multiple paths behind the macrofiles tag are the macro definition related configuration files used when the commands such as RPM and rpmbuild run. The order in the list in the above command output is also the order of the files used when the rpm and rpbuild commands search for macro definitions. Therefore, if the same macro is defined in multiple files, the last one is found. The arrival will take effect eventually. Since ~/.rpmmacros is at the end of the list, each user can change the default definition of a macro on the system by modifying this file in his home directory, such as _topdir.

The following process of this paper expects to use rpmworkshop in mage user's home directory as a "workshop" for RPM package production. It only needs to establish. rpmmacros file in mage user's home directory and redefine macro_topdir in it. The contents of the file are as follows:
%_topdir  /home/mage/rpmworkshop

Then use rpm or rpmbuild command to verify, as follows:

[mage@www.magedu.com ~]$ rpmbuild --showrc | grep "_topdir"
-14: _builddir %{_topdir}/BUILD
-14: _rpmdir %{_topdir}/RPMS
-14: _sourcedir %{_topdir}/SOURCES
-14: _specdir %{_topdir}/SPECS
-14: _srcrpmdir %{_topdir}/SRPMS
-14: _topdir /home/mage/rpmworkshop
//Or:
[mage@www.magedu.com ~]$ rpm --eval '%_topdir'
/home/mage/rpmworkshop

After the modification of the location of the "workshop" for RPM package production, it is necessary to establish the "workshop" and its internal structure. That is to say, as mentioned earlier, this directory should contain five subdirectories: BUILD, RPMS, SOURCES, SPECS and SRPMS. This can be created using the following command:
[mage@www.magedu.com ~]$ mkdir -pv rpmworkshop/{BUILD,RPMS,SOURCES,SPECS,SRPMS}

5.3 Prepare to make RPM package

5.3.1 Prepare to make an overview of RPM packages

Simply put, the process of preparing RPM packages requires placing all the source materials intended to be packaged in the%{topdir}/SOURCES directory and providing a specs file indicating the process in the%{topdir}/SPECS directory. Typically, specs files have the same name as the RPM packages produced and end with. specs for easy identification.

Again, files placed in the%{topdir}/SOURCES directory for packaging can be either source packages in a program archive format, such as nginx-1.0.14.tar.gz, or pure files. However, if the source code is included, in order to produce RPM packages in binary format, the packaging process needs to decompose and compile the source program (compiled in the BUILD directory) before packaging. Otherwise, the compilation of the program is omitted and can be directly packaged.

Taking nginx-1.0.14.tar.gz as the simplest way to make RPM package as an example, we only need to place nginx-1.0.14.tar.gz in the%{topdir}/SOURCES directory and create a file named nginx.spec in the%{topdir}/SPECS directory, and set the relevant instructions for making nginx RPM package in this file. In fact, the process of making spec files is quite complex, but it is also the most critical step in the process of making RPM packages.

Below is a framework spec file, almost all spec files can be extended based on this framework.

Name:
Version:
Release: 1%{?dist}
Summary:
Group:
License:
URL:
pagkager: magedu.com <linuxedu@foxmail.com>
Vendor: http://www.magedu.com/
Source0:
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-XXXXXX
BuildRequires:
Requires:
%description
%prep
%setup -q
%build
%configure
make %{?_smp_mflags}
%install
rm -rf $RPM_BUILD_ROOT
make install DESTDIR=$RPM_BUILD_ROOT
%clean
rm -rf $RPM_BUILD_ROOT
#%pre
#%post
#%preun
#%postun
%files
%defattr(-,root,root,-)
%doc
%changelog

The above framework can be roughly divided into eight parts (see Section 6 of this article for a more detailed introduction).

(1) All the previous contents of% description are defined in the format of "tag: value", including% description, which are descriptions of RPM package-related information. Many of the information is what is displayed when querying it using "rpm-qi". Many tags can be defined by their names, such as Name for defining RPM package names, License for describing its license information, Summary for defining a simple description of this RPM package, and so on. The% description is used to define a RPM package with more detailed description information than in the Summary tag.
(2) The% prep part is the preparation section of the rpm process. If the RPM package is made for a source program in an archive format, the% setup is often used in this section to decompress the source code into the%{topdir}/BUILD directory, and the cd command is used to switch the working directory of the production process to the decompressed source directory. Of course,% setup also has some options for further settings.
(3) The% build part is the build section. If the source material of RPM package is not the source program, this section can be set up without setting; if it is a program of C/C++ class, it corresponds to two steps of "configure" and "make" in its compilation and installation process; if it is a source program of Perl class, it usually corresponds to "perl Makefile.PL" and "make" in its compilation and installation process. The two step. However, in order to keep the compilation environment settings intact during compilation, macro% configure is usually used to replace the configure script here. You can use the "rpm -- eval'% configure'" command to get the relevant definition of the% configure macro on the current system.
(4)%install is the installation stage. When making rpm, all files to be packaged into RPM packages need to be installed in a temporary directory as the simulated system root directory, which is usually called the BUILDROOT directory, according to the path it planned to eventually install on the system. This directory can be defined in a spec file using the "BuildRoot:" tag. Therefore, you can use the%{BuildRoot} reference later, and in fact it can also use the $RPM_BUILD_ROOT reference.
(5)%clean is the cleaning phase. This section is usually used to clean up files created by commands at other stages, such as the "rm-rf $rpm_BUILD_ROOT" command, which removes the BUILDROOT directory that was installed when the previous rpm package was made.
(6)%pre,% post,% preun and% postun are script segments. % Pre is the script to be executed before installation,% post is the script to be executed after installation,% preun is the script to be executed before uninstallation starts, and% postun is the script to be executed after uninstallation completes.
(7)%files section is the file list section. In this section, you need to list all the files packaged into the rpm package, and you need to define permissions for these files after they are installed on the system.
(8)% change log is part of change log segment. This section defines the author of each improvement of the current spec file and the relevant instructions for the improvement.

5.3.2 case

As mentioned in the previous article, the simple production of nginx-1.0.14.tar.gz is an example of RPM. The process is to first place the nginx-1.0.14.tar.gz source package into the%{topdir}/SOURCES directory, where is the / home/mage/rpmworkshop/SOURCES directory. In addition, services installed on Red Hat Linux series Linux systems usually have SysV-style control scripts. In order to make this RPM package basically complete, we need to write a service script of nginx in advance, package it together and install it in / etc/rc.d/init.d/directory at installation time. Therefore, we also need to create this script file in%{topdir}/ SOURCES, which is named nginx.init here, as follows:

#!/bin/sh
#
# nginx - this script starts and stops the nginx daemon
#
# chkconfig:   - 85 15
# description:  Nginx is an HTTP(S) server, HTTP(S) reverse \
#               proxy and IMAP/POP3 proxy server
# processname: nginx
# config:      /etc/nginx/nginx.conf
# config:      /etc/sysconfig/nginx
# pidfile:     /var/run/nginx.pid
# Source function library.
. /etc/rc.d/init.d/functions
# Source networking configuration.
. /etc/sysconfig/network
# Check that networking is up.
[ "$NETWORKING" = "no" ] && exit 0
nginx="/usr/sbin/nginx"
prog=$(basename $nginx)
NGINX_CONF_FILE="/etc/nginx/nginx.conf"
[ -f /etc/sysconfig/nginx ] && . /etc/sysconfig/nginx
lockfile=/var/lock/subsys/nginx
make_dirs() {
   # make required directories
   user=`nginx -V 2>&1 | grep "configure arguments:" | sed 's/[^*]*--user=\([^ ]*\).*/\1/g' -`
   options=`$nginx -V 2>&1 | grep 'configure arguments:'`
   for opt in $options; do
       if [ `echo $opt | grep '.*-temp-path'` ]; then
           value=`echo $opt | cut -d "=" -f 2`
           if [ ! -d "$value" ]; then
               # echo "creating" $value
               mkdir -p $value && chown -R $user $value
           fi
       fi
   done
}
start() {
    [ -x $nginx ] || exit 5
    [ -f $NGINX_CONF_FILE ] || exit 6
    make_dirs
    echo -n $"Starting $prog: "
    daemon $nginx -c $NGINX_CONF_FILE
    retval=$?
    echo
    [ $retval -eq 0 ] && touch $lockfile
    return $retval
}
stop() {
    echo -n $"Stopping $prog: "
    killproc $prog -QUIT
    retval=$?
    echo
    [ $retval -eq 0 ] && rm -f $lockfile
    return $retval
}
restart() {
    configtest || return $?
    stop
    sleep 1
    start
}
reload() {
    configtest || return $?
    echo -n $"Reloading $prog: "
    killproc $nginx -HUP
    RETVAL=$?
    echo
}
force_reload() {
    restart
}
configtest() {
  $nginx -t -c $NGINX_CONF_FILE
}
rh_status() {
    status $prog
}
rh_status_q() {
    rh_status >/dev/null 2>&1
}
case "$1" in
    start)
        rh_status_q && exit 0
        $1
        ;;
    stop)
        rh_status_q || exit 0
        $1
        ;;
    restart|configtest)
        $1
        ;;
    reload)
        rh_status_q || exit 7
        $1
        ;;
    force-reload)
        force_reload
        ;;
    status)
        rh_status
        ;;
    condrestart|try-restart)
        rh_status_q || exit 0
            ;;
    *)
        echo $"Usage: $0 {start|stop|status|restart|condrestart|try-restart|reload|force-reload|configtest}"
        exit 2
esac
#END Of nginx.init

Next, create the nginx.spec file in the%{topdir}/SPECS directory, which reads as follows:

Name:           nginx
Version:        1.0.14
Release:        1%{?dist}
Summary:        A free, open-source, high-performance HTTP server and reverse proxy, as well as an IMAP/POP3 proxy server.
Group:          System Environment/Daemons 
Vendor:  http://www.magedu.com
Packager:  mage <linuxedu@foxmail.com>
License:        BSD
URL:            http://www.nginx.org/
BuildRoot:      %{_tmppath}/%{name}-%{version}-%{release}-root
BuildRequires:      pcre-devel,zlib-devel,openssl-devel
BuildRequires:      libxslt-devel,gd-devel
Requires:           pcre,openssl,gd
# for /usr/sbin/useradd
Requires(pre):      shadow-utils
Requires(post):     chkconfig
# for /sbin/service
Requires(preun):    chkconfig, initscripts
Requires(postun):   initscripts
Provides:           webserver
Source0:    http://sysoev.ru/nginx/nginx-%{version}.tar.gz
Source1:    nginx.init
%description
Nginx is a free, open-source, high-performance HTTP server and reverse proxy,
as well as an IMAP/POP3 proxy server. Igor Sysoev started development of Nginx
in 2002, with the first public release in 2004. Nginx now hosts nearly 12.18%
(22.2M) of active sites across all domains. Nginx is known for its high
performance, stability, rich feature set, simple configuration, and low
resource consumption.
%prep
%setup -q
%build
export DESTDIR=%{buildroot}
./configure \
  --sbin-path=/usr/sbin/nginx \
  --conf-path=/etc/nginx/nginx.conf \
  --error-log-path=/var/log/nginx/error.log \
  --http-log-path=/var/log/nginx/access.log \
  --pid-path=/var/run/nginx/nginx.pid  \
  --lock-path=/var/lock/nginx.lock \
  --user=nginx \
  --group=nginx \
  --with-http_ssl_module \
  --with-http_flv_module \
  --with-http_stub_status_module \
  --with-http_gzip_static_module \
  --http-client-body-temp-path=/var/tmp/nginx/client/ \
  --http-proxy-temp-path=/var/tmp/nginx/proxy/ \
  --http-fastcgi-temp-path=/var/tmp/nginx/fcgi/ \
  --with-pcre
make %{?_smp_mflags}
%install
rm -rf %{buildroot}
make install DESTDIR=%{buildroot}
%{__install} -p -D -m 0755 %{SOURCE1} %{buildroot}%{_initrddir}/%{name}
%{__install} -p -d -m 0755 %{buildroot}/var/run/nginx
%{__install} -p -d -m 0755 %{buildroot}/log/run/nginx
%clean
rm -rf %{buildroot}
%pre
if [ $1 == 1 ]; then
    /usr/sbin/useradd  -s /bin/false -r  nginx 2>/dev/null || :
fi
%post
if [ $1 == 1 ]; then
    /sbin/chkconfig --add %{name}
fi
%preun
if [ $1 = 0 ]; then
    /sbin/service %{name} stop >/dev/null 2>&1
    /sbin/chkconfig --del %{name}
fi
%files
%defattr(-,root,root,-)
%doc LICENSE CHANGES README
%{_sbindir}/%{name}
%dir /var/run/nginx
%dir /var/log/nginx
%dir /etc/nginx
%config(noreplace) /etc/nginx/win-utf
%config(noreplace) /etc/nginx/mime.types.default
%config(noreplace) /etc/nginx/fastcgi.conf
%config(noreplace) /etc/nginx/fastcgi.conf.default
%config(noreplace) /etc/nginx/fastcgi_params
%config(noreplace) /etc/nginx/fastcgi_params.default
%config(noreplace) /etc/nginx/%{name}.conf
%config(noreplace) /etc/nginx/mime.types
%config(noreplace) /etc/nginx/scgi_params
%config(noreplace) /etc/nginx/scgi_params.default
%config(noreplace) /etc/nginx/uwsgi_params
%config(noreplace) /etc/nginx/uwsgi_params.default
%config(noreplace) /etc/nginx/koi-win
%config(noreplace) /etc/nginx/koi-utf
%config(noreplace) /etc/nginx/%{name}.conf.default
/usr/local/nginx/html/50x.html
/usr/local/nginx/html/index.html
%attr(0755, root, root) %{_initrddir}/%{name}
%changelog
* Wed Apr 11 2012 magedu.com <linuxedu@foxmail.com> - 1.0.14-1
- Initial version
# End Of nginx.spec

To ensure that the next production process can proceed smoothly, you can use the nobuild option of the rpmbuild command to test whether the environment on which the spec file depends is fully ready. For example:

[mage@www.magedu.com SPECS]$ rpmbuild --nobuild nginx.spec
error: Failed build dependencies:
 pcre-devel is needed by nginx-1.0.14-1.i386
 gd-devel is needed by nginx-1.0.14-1.i386

The execution of the above command shows that the two rpm packages on which the production process depends have not yet been installed, and the result is that the production process can not be started at all. Therefore, dependencies need to be resolved beforehand. When the test does not have any information, you can start the next section.

5.4 Making rpm Pack

5.4.1 rpmbuild command instructions

The rpm package is made using the rpmbuild command in the following grammatical format:
 rpmbuild  -bBuildStage  spec_file

The - b option is used to tell the rpmbuild command to start making an RPM package, while the BuildStage option is usually a character to control which steps the rpmbuild command takes to make an RPM package based on the specified spec file. The common ways are as follows:
- ba. rpm packages in the generated binary format and rpm packages in the source format are produced simultaneously.
- bb. Only rpm packages in binary format are made.
- bc. Execute only the% build phase in the spec file and stop.
- bp only executes to the% prep stage in the spec file and stops.
- bi: Stop running only at% install stage in spec file;
- bl. Check whether the files listed in the% file section of the spec file match the files in the BUILDROOT directory.
- bs only makes rpm packages that generate source formats;

5.4.2 case

5.4.2.1 Step-by-step implementation of the production process to examine the problems in the implementation process

Still taking the above production process as an example, we carry out the production process in stages to check the problems existing in the relevant steps. Again, it's important to use generic rpm packages as users.

The first step is to test the effect of execution to% prep using the - bp option.

[mage@www.magedu.com SPECS]$ rpmbuild -bp nginx.spec
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.72469
+ umask 022
+ cd /home/mage/rpmworkshop/BUILD
+ LANG=C
+ export LANG
+ unset DISPLAY
+ cd /home/mage/rpmworkshop/BUILD
+ rm -rf nginx-1.0.14
+ /usr/bin/gzip -dc /home/mage/rpmworkshop/SOURCES/nginx-1.0.14.tar.gz
+ tar -xf -
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ cd nginx-1.0.14
++ /usr/bin/id -u
+ '[' 502 = 0 ']'
++ /usr/bin/id -u
+ '[' 502 = 0 ']'
+ /bin/chmod -Rf a+rX,u+w,g-w,o-w .
+ exit 0

The output of the command indicates that this step is normal, nginx-1.0.14.tar.gz is decompressed into the / home/mage/rpmworkshop/BUILD/directory, and before decompression, attempts are made to delete the previously decompressed files, etc.

The second step is to use the - bc option to restart the production process and execute it to the% build section.
[mage@www.magedu.com SPECS]$ rpmbuild -bc nginx.spec
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.46906
... ...
... ...
# (Several lines of output as in the first step are omitted here.)

Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.46906
+ umask 022
+ cd /home/mage/rpmworkshop/BUILD
+ cd nginx-1.0.14
+ LANG=C
+ export LANG
+ unset DISPLAY
+ export DESTDIR=/var/tmp/nginx-1.0.14-1-root
+ DESTDIR=/var/tmp/nginx-1.0.14-1-root
+ ./configure --sbin-path=/usr/sbin/nginx '--conf-path=%{nginx_confdir}/nginx.conf' --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx/nginx.pid --lock-path=/var/lock/nginx.lock --user=nginx --group=nginx --with-http_ssl_module --with-http_flv_module --with-http_stub_status_module --with-http_gzip_static_module --http-client-body-temp-path=/var/tmp/nginx/client/ --http-proxy-temp-path=/var/tmp/nginx/proxy/ --http-fastcgi-temp-path=/var/tmp/nginx/fcgi/ --with-pcre
checking for OS
... ...
... ...

# (omitting lines of output)
make[1]: Leaving directory `/home/mage/rpmworkshop/BUILD/nginx-1.0.14'
+ exit 0

As you can see from the output above, the% build phase executes the configure script and make command and successfully ends.

The third step is to use the - bi option to restart the production process and execute it to the% install section.
[mage@www.magedu.com SPECS]$ rpmbuild -bc nginx.spec
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.46906
... ...
... ...
# (Several lines of output as in the first step are omitted here.)
Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.46906
... ...
... ...
# (Several lines of output as in step 2 are omitted here.)
rocessing files: nginx-debuginfo-1.0.14-1
Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1
Checking for unpackaged file(s): /usr/lib/rpm/check-files /var/tmp/nginx-1.0.14-1-root

As can be seen from the last line of the above information, compiled programs and so on have been successfully installed in the path with / var/tmp/nginx-1.0.14-1-root as the root directory (this directory is BUILDROOT), and the spec file specifies that the files to be packaged match the files generated by the installation under this directory.

In this step, it is very easy to make mistakes if we do not consider it carefully. There are usually two types of errors: one is that the files installed in the BUILDROOT directory are not packaged by spec; the other is that the spec file specifies to be packaged, but this file does not exist in BUILDROOT. These two kinds of errors are easy to solve, just need to carefully compare the files listed in the% files section of BUILDROOT and spec files. Of course, we can also delete files that do not want to be packaged after the installation process in the spec file has been completed, thus eliminating the need to include such files in the% files section.

5.4.2.2 Making rpm Pack of nginx

If there are no problems with the phased implementation process in Section 5.4.1.1, then we can start making real rpm packages. Generally speaking, RPM can be made only in binary format, or only in source format, or both. Only, they need to be implemented using different options of the rpmbuild command. Refer specifically to the description in section 5.4.1.

Let's make a package that generates binary format and a package that generates source format at the same time. This can be achieved by using the following commands:
[mage@www.magedu.com SPECS]$ rpmbuild -ba nginx.spec

The last few lines of the command execution output are usually as follows:

Wrote: /home/mage/rpmworkshop/SRPMS/nginx-1.0.14-1.src.rpm
Wrote: /home/mage/rpmworkshop/RPMS/i386/nginx-1.0.14-1.i386.rpm
Wrote: /home/mage/rpmworkshop/RPMS/i386/nginx-debuginfo-1.0.14-1.i386.rpm
Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.33201
+ umask 022
+ cd /home/mage/rpmworkshop/BUILD
+ cd nginx-1.0.14
+ rm -rf /var/tmp/nginx-1.0.14-1-root
+ exit 0

The output shows that the command finally generates three rpm packages, of which nginx-1.0.14-1.src.rpm in source format is in SRPMS directory, nginx-1.0.14-1.i386.rpm in binary format is in RPMS/i386 directory (i386 directory is mainly used to indicate the platform of RPM produced), and nginx-debugo-1.0.14-1.i386.rpm is in SRPMS directory. Debugging the RPM package where the program or file used to run nginx is located.

5.4.2.3 View completed rpm package summary information

For completed rpm packages, the summary information is generated by the tag section definition in the spec file. For non-installed rpm packages, you can use the - qpi option of the rpm command.

[mage@www.magedu.com ~]$ rpm -qpi ~/rpmworkshop/RPMS/i386/nginx-1.0.14-1.i386.rpm
Name        : nginx                        Relocations: (not relocatable)
Version     : 1.0.14                            Vendor: http://www.magedu.com
Release     : 1                             Build Date: Wed 11 Apr 2012 05:01:14 PM CST
Install Date: (not installed)               Build Host: mail.magedu.com
Group       : System Environment/Daemons    Source RPM: nginx-1.0.14-1.src.rpm
Size        : 705987                           License: BSD
Signature   : (none)
Packager    : mage <linuxedu@foxmail.com>
URL         : http://www.nginx.org/
Summary     : A free, open-source, high-performance HTTP server and reverse proxy, as well as an IMAP/POP3 proxy server.
Description :
Nginx is a free, open-source, high-performance HTTP server and reverse proxy,
as well as an IMAP/POP3 proxy server. Igor Sysoev started development of Nginx
in 2002, with the first public release in 2004. Nginx now hosts nearly 12.18%
(22.2M) of active sites across all domains. Nginx is known for its high
performance, stability, rich feature set, simple configuration, and low
resource consumption.

So far, the rpm package of nginx-1.0.14 has been made and can be distributed to the corresponding platform for installation. However, rpm packages have not yet been signed, and there is still much work to be done to customize rpm packages that belong to a particular environment. These will be discussed in later chapters.

VI. SPECS Document Explanation
7. Use rpmbuld command to control the production process
8. Implementation of RPM Packet Signature
Nine, case
10. Summary of Problems