Production of RPM packages

Introduction to the production of RPM packages

According to the format of its package, the common Linux distribution can be divided into two categories, class Readhat series and class Debian series , which provide their own software package management system and corresponding tools.

The suffix of the package in the class Redhat system is RPM, which provides the RPM command with the same name to install, uninstall, and upgrade the RPM package, and the suffix of the Debian system is Deb, which also provides the dpkg command to the suffix Deb.

RPM is the full name of Redhat package Manager, and the most common systems for using RPM packages are Fedora, CentOS, OpenSUSE, SuSE Enterprise, PCLinuxOS, and Mandriva Linux, Mageia, and more. The most common Debian systems that use the Deb package suffix are Debian, Ubuntu, Finnix, and so on.

Either the rpm command or the DPKG command has a package dependency problem when installing the package.

The Fedora/centos system provides the installation dependency of Yum from the dynamic solution package, and the opensuse/suse system provides the installation dependency of the Zypper from the dynamic solution package; The C6>mandriva Linux/mageia system provides URPMI installation dependencies from the dynamic solution package, and the Debian/ubuntu system provides apt-* commands.

These tools essentially eventually call the rpm (or dpkg) to install, but will automatically help the user to resolve the installation dependency of the package before installation.

From the structure of software operation, a software can be divided into three parts: executable program, configuration file and dynamic library. Of course, there may be documentation, manuals, header files for two development, and some sample programs, among other things. Other parts are optional and only executable files are required.

The usual way to make RPM packages is to use the rpmbuild command-line tool.

Installing the Rpmbuild tool

You can perform the Yum Command Installation Toolkit (where you can connect to the Internet):

yum install rpm* rpm-build rpmdev*

or use the RPM package to directly connect the installation (with the case of the Rpm-build installation package):

rpm -ivh rpm-build-4.8.0-37.el6.x86_64.rpm

If you still need to install the Rpmdevtools tool, it's a little cumbersome and needs to be seen on your own to install.

Rpmbuid Packing Directory

The RPM Packaging directory has some stringent requirements on the level.

RPM version <=4.4.x,rpmbuid tool its default working path is /usr/src/redhat because of the problem of permissions, ordinary users can not make RPM package, the production of RPM software package must switch to root Identity can only be.

RPM starts with the 4.5.x version, moving the default working path of Rpmbuid to the Rpmbuild directory in the user's home directory, i.e. $HOME/rpmbuild , and recommends that users do not operate as root as possible when making RPM packages.

Rpmbuild the default working path, usually defined by a macro variable called %_topdir in the /usr/lib/rpm/macros file. If the user wants to change this directory name, RPM is not recommended to change the directory directly, but in the user's home directory to create a hidden file named . Rpmmacros (hidden files under Linux, the front point must not be less), and then redefine the inside %_ Topdir, point to a new directory name. This will satisfy the differentiated needs of some users. Typically, there is only one line of content in the. rpmmacros file, such as:

%_topdir    

6 directories are generally required under the%_topdir directory

Directory name	Description	the name of the macro in macros
BUILD	Compile the Temp directory for RPM packages	%_builddir
BuildRoot	Software temporary installation directory generated after compilation	%_buildrootdir
RPMS	The directory where the final generated installable RPM package is located	%_rpmdir
SOURCES	Storage directory for all source code and patch files	%_sourcedir
SPECS	directory where spec files are stored	%_specdir
SRPMS	Software final RPM source format storage Path	%_srcrpmdir

If you have Rpmdevtools installed, you can use the Rpmdev-setuptree command to automatically create the above directory in the current user Home/rpmbuild directory.

Spec file detailed Note:

The LIUNX environment can use VI to edit the spec file, and the Windows environment can use sublime to edit the spec file. Note that it is absolutely not possible to edit with Notepad, because the default line break for Windows is \r\n , and Liunx is the newline character \n . If the spec file contains extra, \r it will cause the RPM package creation to fail.

The file uses Liunx style, that is, line break is \n , so it is recommended to use VI to edit the spec file, because if

When the packaged directory is set up, all the source code, shell scripts, and configuration files used to generate the RPM package are copied to the sources directory, noting that the source code is normally compressed in *.tar.gz format. Then, the most important spec file, the naming format is generally "software name-version. Spec" form, copy it to the specs directory, switch to the directory to execute:

If the system has rpmdevtools tools, you can use the Rpmdev-newspec-o name-version.spec command to generate a template for the spec file, and then modify it:

If you do not have Rpmdevtools installed, you can manually create a spec file yourself

Spec file content:

The core of the spec file is that it defines "stages" (%prep,%build,%install, and%clean), and when Rpmbuild executes it first parses the spec file and executes the instructions in each "stage" in turn.

Spec's head content description:

    Name:                  myapp  ←←←软件包的名字    Version:               0.1.0  ←←←软件包的版本    Release:               1%{?dist} ←←←发布序号     Summary:               my first rpm ←←←软件包的摘要信息     Group:                 ←←←软件包的安装分类，参见/usr/share/doc/rpm-4.x.x/GROUPS这个文件     License:               GPL ←←←软件的授权方式     URL:                   ←←←源码包的下载路径或者自己的博客地址或者公司网址之类     Source0:               %{name}-%{version}.tar.gz ←←←源代码包的名称(默认时rpmbuid回到SOURCES目录中去找)，这里的name和version就是前两行定义的值。如果有其他配置或脚本则依次用Source1、Source2等等往后增加即可。     BuildRoot:             %{_topdir}/BUILDROOT ←←←这是make install时使用的“虚拟”根目录，最终制作rpm安装包的文件就来自这里。     BuildRequires:         ←←←在本机编译rpm包时需要的辅助工具，以逗号分隔。假如，要求编译myapp时，gcc的版本至少为4.4.2，则可以写成gcc >=4.2.2。还有其他依赖的话则以逗号分别继续写道后面。     Requires:              ←←←编译好的rpm软件在其他机器上安装时，需要依赖的其他软件包，也以逗号分隔，有版本需求的可以     %description           

Make RPM package for each stage description:

Production RPM package has %prep,%build,%install,%files,%clean several key stages.

%prep Stage

This phase of the general situation, the main completion of the source code package decompression and patching , and the most common decompression is an instruction:

Extract the source code under the %sourcedir directory to the%builddir directory.

%build Stage

This phase will execute the source package compilation in the %_builddir directory. It is generally performed to perform common configure and make operations, and if some software needs to be executed first bootstrap and so on, it can be done before configure.

At this stage we are most likely to have only two instructions:

It automatically sets the path of the software installation to the following conventions:

1. Executable program/usr/bin
2. Dependent dynamic libraries/usr/lib or/usr/lib64 depending on the operating system version.
3. Two development of header files/usr/include
4. Documents and Manuals/usr/share/man

The %configure here is a macro constant that automatically sets the prefix to/ usr . In addition, this macro can accept additional parameters, if some of the software has some advanced features need to be turned on, you can pass to the%configure macro parameters to open. If you do not have to%configure this macro, you need to fully manually specify the configuration parameters configure. Similarly, we can pass additional parameters to make, such as:

%install Stage

This phase is the make install operation, which builds the directory structure in the%Buildrootdir directory, and then copies the files that need to be packaged into the RPM package from%BuildDir to%_ In the corresponding directory in the Buildrootdir.

When the user eventually rpm -ivh name-version.rpm installs the package, the files are installed in the appropriate directory on the user's system.

The two most common instructions at this stage are:

where $RPMBUILDROOT can also be replaced with the BuildRoot variables we defined earlier, but to write %{buildroot} , you must use all lowercase, or you will get an error.

If the software has a configuration file or an additional startup script, you will need to copy it to the corresponding directory using the copy command or the install command, either manually or%{buildroot. When using the Copy command, if the directory does not exist to be manually established, it will also error, so it is recommended to use the install command.

%files Stage

This phase is used primarily to indicate which files and directories under the%{buildroot} directory will eventually be packaged in the RPM package.

The syntax for the first command in the%files phase is:

If you do not involve the file, directory permissions change is generally used%defattr (-,root,root,-) This directive to set default permissions for it. All files and directories that need to be packaged into RPM packages are listed in this place, for example:

When the RPM is installed, the executable binaries are placed in the/usr/bin directory, the dynamic libraries are placed in the/usr/lib or/usr/lib64 directory, the configuration files are placed in the/etc directory, and multiple installations of the newly-installed configuration file will not overwrite the previously existing configuration file with the same name. Here when you write the list of files to be packaged, you can either start with a macro constant or start with a "/", without any essential difference, which means copying the file from%{buildroot} to the final RPM package, or, in the case of a relative path, the file to be copied in the%{_builddir} directory. This applies primarily to files that are not copied to the%{buildroot} directory at the%install stage, most commonly files such as readme, license, and so on. If you do not want to package some files or directories in%{buildroot} into RPM, use: %exclude dic_name orfile_name

There are two features about the%files phase:

1. All files in%{buildroot} must be explicitly specified to be packaged in RPM. What do you mean? If,%{buildroot} directory has 4 directories A, B, C and D, in%files only specify a and B to package to RPM, if not the C and D with the Exclude declaration is to error;
2. If a file or directory that does not exist in the%{buildroot} is declared, an error will be made.

About%doc macros, all files following this macro are from the%{_builddir directory, and when the user installs the RPM, the files specified by the macro are installed in the/usr/share/doc/name-version/directory.

Package Production phase

This phase is automatically completed, so in the spec file is not visible, this phase will be the %buildroot directory of related files into the RPM package eventually put to % in the Rpmdir directory.

%clean Stage

Some cleanup work after compilation is done, mainly including emptying the Directory of%{buildroot} (which is not required), and usually executes commands such as make clean.

%changelog Stage

This is the last stage of the main record of each package when the change log is modified. The standard format is:

RPM Packaging Process Summary

1. Installing Rpmbuild
2. Build a compiled directory structure for RPM: Rpmbuild/├build├rpms├sources├specs└srpms
3. Put the source into rpmbuild/sources
4. Creating a spec file in the Rpmbuild/specs directory
5. To perform a packaged compilation under the Rpmbuild/specs directory: rpmbuild -bb xxxxx.spec
6. The final generated RPM package

Spec File Template

Below is a complete set of spec file templates that contain patching, installation, and uninstallation features.

Name: test Version: Requires: %description … #==================================SPEC头部==================================== %prep %setup -q %patch <==== 在这里打包 %build %configure make %{?_smp_mflags} %install rm -rf $RPM_BUILD_ROOT make install DESTDIR=$RPM_BUILD_ROOT %clean rm -rf $RPM_BUILD_ROOT %files %defattr(-,root,root,-) 要打包到rpm包里的文件清单 %doc %changelog #==================================SPEC主体==================================== %pre 安装或者升级软件前要做的事情，比如停止服务、备份相关文件等都在这里做。 %post 安装或者升级完成后要做的事情，比如执行ldconfig重构动态库缓存、启动服务等。 %preun 卸载软件前要做的事情，比如停止相关服务、关闭进程等。 %postun 卸载软件之后要做的事情，比如删除备份、配置文件等。

Appendix: Rpmbuild Related Commands

Basic format: rpmbuild [options] [Spec Document |tarball Package | Source Package]

1. The following options are available from the spec document:-BP #只执行spec的%pre Segment (unpack the source package and patch, i.e. prepare only)-BC #执行spec的%pre and%build segments (prepare and compile)-bi #执行spec中%pre,%build and%install (Prepare, compile and install)-BL #检查spec中的%file segment (see if the file is complete)-ba #建立源码与二进制包 (Common)-bb #只建立二进制包 (common)-bs #只建立源码包

2. Built from the Tarball package, similar to spec-TP #对应-bp-tc #对应-bc-ti #对应-bi-ta #对应-ba-tb #对应-bb-ts #对应-bs

3. Build--rebuild #建立二进制包 from source package, pass-BB--recompile #同-bi

4. Some of the other options are--buildroot=directory #确定以root目录建立包--clean #完成打包后清除BUILD下的文件目录--nobuild #不进行%build stage--nodeps #不检查建立包时的关联文 Pieces--nodirtokens--rmsource #完成打包后清除SOURCES--rmspec #完成打包后清除SPEC--short-cricuit--target=cpu-vendor-os #确定包的最终使用平台

The writing of spec documents

Name: The names of the packages, which can be referenced later using%{name}, the specific command needs to be consistent with the source package Summary: The contents of the package version: The actual release number of the software, the specific command needs to be consistent with the source package release: Release serial number, the specific command needs to be consistent with the source package

Group: Software grouping, it is recommended to use the standard grouping package category, the specific categories are: Amusements/games (Entertainment/game) Amusements/graphics (Entertainment/graphics) applications/archiving (application/ Document) Applications/communications (application/Communication) applications/databases (application/database) Applications/editors (application/editor) applications/ Emulators (application/Emulator) applications/engineering (application/Engineering) Applications/file (application/file) applications/internet (application/Internet) Applications/multimedia (application/Multimedia) applications/productivity (application/Product) applications/publishing (application/printing) applications/ System (application/System) Applications/text (application/text) development/debuggers (dev/debugger) development/languages (dev/language) development/ Libraries (Development/function Library) Development/system (Development/System) Development/tools (Development/tools) documentation (documentation) System Environment/base (System environment /base) System Environment/daemons (System environment/daemon) system Environment/kernel (System environment/kernel) system environment/libraries (System environment/function library) System Environment/shells (Systems Environment/interface) user interface/desktops (user interface/Desktop) user interface/x (User interface/X window) User interface/x Hardware Support (user interface/x hardware supported)

License: Software licensing method, usually is the GPL Source: Code package, you can take multiple with Source1, Source2 and other sources, can also be used after%{source1},%{source2} reference BuildRoot: This is installed or compiled using the " Virtual directory ", considering the multi-user environment, is generally defined as:%{_tmppath}/%{name}-%{version}-%{release}-root1Or%{_tmppath}/%{name}-%{version}-%{release}-buildroot-%(%{__id_u} -n}This parameter is important because in the process of generating the RPM, the software is installed in the path above when the make install is executed, and it is also dependent on the "virtual directory" for the "root directory" when packaging. You can refer to it later using the $rpm_build_root method. URL: Software's home page Vendor: Information for publishers or packaged organizations, such as Redflag Co,ltd disstribution: Release identity Patch: Patch source, can use PATCH1, PATCH2, etc. to identify multiple patches, using%patch0 or%{ Patch0} reference Prefix:%{_prefix} This is mainly to solve the problem of installing the RPM package in the future, not necessarily the software installed in the RPM packaging directory. In this way, the identity must be defined here and referenced at the time of writing the%install script to implement the function of re-specifying the location at RPM installation Prefix:%{_sysconfdir} This is the same reason as above, but because%{_prefix}/usr, and for other files, such as config file under/etc, you need to use%{_sysconfdir} to identify the build Arch: The target processor schema for the compilation, the Noarch identity is not specified, but it is usually/usr/lib/rpm/ The content in Marcros is the default value Requires: The package name that the RPM package relies on can be expressed in >= or <= to be greater than or less than a specific version, for example: Libpng-devel >= 1.0.20 zlib※ ">=" Both sides are separated by a space, and different software names are also separated by spaces such as Prereq, Requires (pre), Requires (POST), Requires (Preun), Requires (Postun), Buildrequires, etc. are for different stages of dependency designation provides: Specify some specific features of the software so that other RPM Identification Packager: Details of the packager scription software

Spec Script Body

Many keywords and descriptions are included in the main body of the spec script, which is listed below. I'll mark out some places that I need to pay special attention to. %prep preprocessing script%setup-n%{name}-%{version} Extract the source package and put it well note: According to your source name format, to confirm the format of the name after the decompression, otherwise it may cause the install when the corresponding directory is usually found from the/usr/src/ The package in the redhat/sources is extracted to/usr/src/redhat/build/%{name}-%{version}. Generally with%setup-c can be, but there are two cases: one is to compile multiple source packages at the same time, two is the source of the tar package name and extracted out of the directory inconsistency, at this time, you need to use the-n parameter specified. %patch patching is usually patched together in the source tar.gz package, or placed in the sources directory. The general parameters are:%PATCH-P1 using the patch patches defined previously,-P1 is the first level of the Ignore patch%patch2-p1-b xxx.patch The specified patch,-B refers to the generation of backup files

Supplemental%setup does not have any options to open the package only. %setup-n Newdir Unpack the package in the Newdir directory. The directory is generated before%setup-c is decompressed. %setup-b NUM Unzip the first num source file. %SETUP-T does not use the default decompression operation. %setup-t-B 0 uncompress the No. 0 source code file. %SETUP-C-N newdir Specifies the directory name Newdir and generates the RPM suite in this directory. %patch The simplest patch level, automatically specify patch level. %patch 0 uses the No. 0 patch file, which is equivalent to%patch P 0. %patch-s does not display the information when patching. %PATCH-T removes all output files that are generated when the patch is hit.

%build started building packages in the/usr/src/redhat/build/%{name}-%{version} directory to make the work, common wording: makes%{? SMPMflags} optimize= "%{optflags}" are some of the optimization parameters defined in/usr/lib/rpm/marcros

%install began to install the software into the virtual root directory in the/usr/src/redhat/build/%{name}-%{version} directory for make install operation. This is important because if the path is not correct, the following%file will fail when looking for a file. Common content is:%makeinstall This is not a keyword, but a standard macro command defined by RPM. You can also use non-standard notation: Make destdir= $RPMbuildroot install or makes prefix= $RPMbuildroot Install

It should be explained that the%install here is mainly for the sake of the back of the%file service. Therefore, you can also use the general system commands:

install-d $RPMBuildroot/#建立目录 cp-a * $RPMbuildroot/

%clean Cleanup temp file typically includes: reference ["$RPMbuildroot"! = "/"] && rm-rf "$RPMBUILDroot" rm-rf $RPMBuil DDir/%{name}-%{version}

※ Note the distinction between $rpm_build_root and $rpm_build_dir: $RPM _build_root refers to the buildroot defined at the beginning, and $rpm_build_dir usually refers to/usr/src/redhat/build, Among them, the front is the%file need.

%pre rpm scripts executed before%post rpm after the installation of the script%preun rpm before the uninstall script executed%postun rpm after unloading the script executed%preun%postun The difference is: The former will be executed during the upgrade, The latter will not execute when upgrading the RPM package

%files defines those files or directories that are placed in the RPM, which is done in the virtual root directory, never write absolute paths, and apply macros or variables to represent relative paths. If described as a directory, represents all files in the directory except%exclude. Fattr (-,root,root) Specifies the properties of the wrapper file, respectively (Mode,owner,group), which represents the default value, the text file is 0644, and the executable is 0755

%exclude list files that you do not want to pack into RPM ※ Be careful, if the file specified by%exclude does not exist, it will be wrong. %changelog Change Log

Several macros (variables) commonly used in spec documents

1. Rpm_build_dir:/usr/src/redhat/build
2. Rpm_build_root:/usr/src/redhat/buildroot
3. %{_sysconfdir}:/etc
4. %{_sbindir}:/usr/sbin
5. %{_bindir}:/usr/bin
6. %{_datadir}:/usr/share
7. %{_mandir}:/usr/share/man
8. %{_libdir}:/usr/lib64
9. %{_prefix}:/usr
10. %{_localstatedir}:/usr/var

RPM Common Commands

• Install RPM Packages manuallyrpm-ivh xxxxx.rpm

• View RPM Package Informationrpm-qpi xxxxx.rpm

• View RPM Package Dependenciesrpm -qpR xxxxx.rpm

• View RPM packages containing those files rpm -qlp xxxxx.rpm can be added grep searchrpm -qlp xxxxx.rpm|grep spec

• To extract files using the tool Rpm2cpio:rpm2cpio xxxxx.rpm |cpio -ivd xxx.jpg

• Convert rpm files to cpio file using Rpm2cpiorpm2cpio xxxxxx.rpm >xxxxx.cpio

• Extracting Cpio files with Cpiocpio -i  --make-directories

• Extract all Files: rpm2cpio xxx.rpm | cpio -vi rpm2cpio xxx.rpm | cpio -idmv rpm2cpio xxx.rpm | cpio --extract --make-directories

• Cpio parameter Description: i and extract indicate that the extract file v indicates that the execution process D and make-directory represent the files in the package according to The original path creation directory m means to keep the file updated time

• Check the pre and post install scripts in the RPM package: rpm -qp --scripts xxxxx.rpm

• To view the process of the installation, the code executes:rpm -ih -vv xxxxx.rpm

Production of RPM packages