Making RPM Packages

Common Linux distributions can be divided into two categories, the Class Readhat series and the Debian series, where we are divided in the format of their packages, which provide their own package management systems and corresponding tools. The suffix of the package in the class Redhat system is rpm; the suffix of the package in the class Debian system is Deb. On the other hand, the class Redhat system provides an RPM command with the same name to install, uninstall, and upgrade the RPM package; The class Debian system also provides the DPKG command to install, uninstall, and upgrade the software bundle that is the suffix Deb.
RPM is the full name of Redhat Package Manager, the common use of RPM software packages are mainly Fedora, CentOS, OpenSUSE, SUSE Enterprise Edition, PCLinuxOS and Mandriva Linux, Mageia and so on. Debian, Ubuntu, Finnix, and so on are the most common types of Debian systems that use the Deb package suffix.

Both the RPM command and the dpkg command have a very troubling problem with installing the package, which is the dependency of the package. This is something that many people should be aware of, which also makes it very inconvenient for beginners to touch Linux systems. Thankfully, many distributions have taken this into account, so fedora and CentOS provide yum from the installation dependencies of the dynamic solution package, the same openSUSE provides Zypper, and the class Debian system provides apt-* commands. This means that these tools essentially eventually call RPM (or dpkg), but they automatically solve the installation dependencies of the packages before they are installed. As shown in the following table:

Classification	Release version	Manual installation Command	Automatic installation command	Package suffix
Class Redhat	Fedora/centos	Rpm	Yum	*.rpm
Opensuse/suse	Zypper
Mandriva Linux/mageia	Urpmi
Class Debian	Debian/ubuntu	Dpkg	Apt-get	*.deb

     to put it simply, if you're going to use Yum from the dynamic installation package on Fedora or CentOS, you'll use Apt-get to automatically install the software on Debian or Ubuntu, On openSUSE you will automatically install the package with Zypper.

    This document mainly describes how to build your own RPM software installation package from the source code of the package.
    From the structure of software running, 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, some sample programs, and so on. Other parts are optional, and only executable files are required.
    about how to make RPM software packages, online tutorials are also a lot of the most talked about when the rpmbuild this command-line tool. This article is to introduce the "Supporting Role", and the protagonist is its input object, that is, the so-called spec file format, writing and description. The

   rpm packaging process is a bit more cumbersome than Deb's because it has some stringent levels of requirements for the packaged directory. If your RPM version is <=4.4.x, then the Rpmbuid tool's default working path is/usr/src/redhat, which makes it impossible for ordinary users to make RPM packages because of permissions, you must switch to root when making RPM packages. So rpm starts with the 4.5.x version, moves the RPMBUID default work path to the Rpmbuild directory in the user's home directory, $home/rpmbuild, and recommends that users do not operate as root when making RPM packages.

    about the Rpmbuild default work 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, the RPM official does not recommend to change this directory directly, but creates a hidden file named. Rpmmacros in the user's home directory (note that the front point is not less, this is the common sense of hidden files under Linux), and then redefine the%_topdir in it, Point to a new directory name. This will meet the differentiated needs of some "advanced" users. Typically, the. rpmmacros file contains only one line of content, such as:

Click (here) to collapse or open%_topdir $HOME/myrpmbuildenv

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 the RPM package	%_builddir
BuildRoot	Post-compiled software temporary installation directory	%_buildrootdir
RPMS	The directory where the resulting installable RPM package will be built	%_rpmdir
SOURCES	Directory of all source code and patch files	%_sourcedir
SPECS	directory where spec files are stored (important)	%_specdir
Srpms	Software final RPM source format storage path (temporarily ignored, do not hang in mind)	%_srcrpmdir

Tips: Performing Rpmdev-setuptreeThe directory is automatically created in the Rpmbuild directory in the current user's home directory (if the directory does not exist).
When the above directory is established, copy all source code, shell scripts, and configuration files that are used to generate the RPM package into the sources directory, and note usuallyIn the case of the source code compression format is *.tar.gz format (of course, but also for other formats, but that is another way, here first). Then, the most important spec file, named format is generally "software name-version. Spec" form, copy it to the specs directory, switch to the directory to execute:

Click (here) to collapse or open the RPMBUILD-BB software name-version. Spec
In the end, we wanted the RPM package to lie peacefully in the RPMs directory. Yes, it's that simple.
The key here is the above spec file, we can use Rpmdev-newspec-o name-version.spec command to generate spec file template, and then modify on the above can. For example:

Click (here) to collapse or open [root@localhost ~]# rpmdev-newspec-o Myapp-0.1.0.spec
Skeleton Specfile (minimal) has been created to "Myapp-0.1.0.spec".
[Root@localhost ~]# cat Myapp-0.1.0.spec name:myapp-0.1.0
Version:
Release:1%{?dist}
Summary:

Group:
License:
Url:
SOURCE0:
BuildRoot:%{_tmppath}/%{name}-%{version}-%{release}-root-% (%{__id_u}-N)

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

%files
%defattr (-,root,root,-)
%doc

%changelog

     The core of the spec file is that it defines some "stages" (%prep,%build,%install, and%clean) that, when Rpmbuild executes, will first parse the spec file. Then execute the instructions in each "stage" in turn.
    Next, let's take a quick look at the head of the spec file. If, our source code package name is myapp-0.1.0.tar.gz, then Myapp-0.1.0.spec's head generally looks like this:

Click (here) to collapse or open Name:                  myapp                  <=== software package name (used later) Version:               0.1.0                   <=== software package (later) Release:               1%{? dist}              <=== Release serial number Summary:               my rpm           < = = = Package summary information Group:          ,     <=== software package installation category, see/usr/share/doc/rpm-4.x.x/ Groups this file License:               gpl  <=== Software's authorized way URL:       &N Bsp           <=== here would have written the source package download path or your own blogAddress or company URL Source0:              %{name}-%{version}.tar.gz <=== source code package name ( The default is to rpmbuid back to the sources directory, where name and version are the values defined in the first two lines. If there are other configurations or scripts, then add Source1, Source2, and so forth. BuildRoot:             %{_topdir}/buildroot <=== This is the "virtual" root directory used for make install, The file that eventually makes the RPM installation package comes from here. Buildrequires:         <=== the auxiliary tools needed to compile the RPM package in the native, separated by commas. If, when compiling MyApp is required, GCC version is at least 4.4.2, then it can be written as GCC >=4.2.2. There are other dependencies that continue to be written after the comma, respectively. Requires:          -   <=== compiled RPM software when installed on other machines, other packages that need to be relied upon are also separated by commas, and the version requirements can be% Description           <=== software package details, but can only have 80 English characters.

Let's take a look at some of the key stages of making the RPM package, and what's going on:

Stage	Action
%prep	Extract the source code under the%_sourcedir directory into the%_builddir directory. If there are patches that need to be patched in this phase of the operation
%build	Execute the compilation of the source package in the%_builddir directory. Generally executes./configure and make Directives
%install	Files that need to be packaged into the RPM package are copied from the%_builddir under the%_buildrootdir directory. When the user finally installs the package with RPM-IVH name-version.rpm, the files are installed in the corresponding directory in the user's system.
Making RPM Packages	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 into the%_rpmdir directory
%clean	Post-compilation cleanup, where you can perform make clean and clear the%_buildroot directory

The details of each phase are as follows: %prep phase in this phase of the general situation, the main completion of the source code package decompression and patching (if any), and decompression is the most common to a sentence:

Click (here) to collapse or open%setup-q

Of course, this instruction can be successfully executed if you are located in the sources directory of the source package must be name-version.tar.gz format, it will also complete the next phase of the directory switch and settings. If you do not use this instruction at this stage, then each subsequent stage will have to manually change the corresponding directory. If there is a patch file after the decompression is done, do it here. Want to know the children's shoes can go to find out how to achieve, it is not difficult, here I will not expand.

%build phase This phase is to perform common configure and make operations, if some software needs to perform the first bootstrap, and so on, can be placed before configure. At this stage we are the most common only two instructions:

Click (here) to collapse or open%configure make%{?_smp_mflags}

It automatically sets the path of the software installation to the following conventions:
executable program /usr/bin Dependent Dynamic Libraries /usr/lib or /usr/lib64 depends on the operating system version. Two development of header document /usr/include documents and manuals /usr/share/man

Note that the%configure here is a macro constant that automatically sets the prefix to/usr. In addition, the macro can accept additional parameters, and if some of the software has some advanced features that need to be turned on, it can be opened by giving the%configure macro pass parameters. If you don't have to%configure this macro, you need to completely manually specify the configuration parameters for configure. Similarly, we can pass extra parameters to make, for example:

Click (here) to collapse or open make%{?_smp_mflags} cflags= "" ...

%install Stage

This stage is to perform the make install operation. This phase 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 the corresponding directory in%_buildrootdir. The most common two instructions for this phase are:

Click (here) to collapse or open RM-RF $RPM _build_root make install destdir= $RPM _build_root

One of the $rpm_build_root can also be replaced by the BuildRoot variable we defined earlier, but to write%{buildroot} can only, must be all lowercase, or to the error.
If the software has a configuration file or an additional startup script, either manually use the Copy command or the install command to copy it to the corresponding directory in%{buildroot. When you use the Copy command, if the directory does not exist to manually build, otherwise it will also error, so the recommended install command.

%clean Stage

Some cleanup work after compilation, including the emptying of the%{buildroot} directory (which is not necessarily necessary), usually executes commands such as make clean.

Making rpm The phase of the software package must lead to the following phase called%files. It is mainly used to explain which files and directories in the%{buildroot} directory will eventually be packaged into the RPM package.

Click (here) to collapse or open%files%defattr (-,root,root,-)%doc

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

Click (here) to collapse or open%defattr (file permissions, username, group name, directory permissions)

If you do not involve a change in file or directory permissions, you typically set the default permissions for the%DEFATTR (-,root,root,-) directive. All files and directories that need to be packaged into the RPM package are listed in this location, such as:

Click (here) to collapse or open%files%{_bindir}/*%{_libdir}/*%config (noreplace)%{_sysconfdir}/*.conf

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 under the/etc directory, and a newer configuration file is installed multiple times without overwriting a previously existing profile with the same name.
Here, when you write a list of files to package, you can either start with a macro constant or start with a "/", without any essential distinction , which means copying the file from%{buildroot} to the final RPM package; if it is a relative path, the file to be copied is located in the%{_ BuildDir} directory, which is primarily applicable to files that are not copied to the%{buildroot} directory in the%install phase, and most commonly files such as readme and license. If you do not want to package some files or directories in%{buildroot} into RPM, use:

Click (here) to collapse or open%exclude dic_name or file_name

But there are two features to remember about the%files phase:
All files in%{buildroot must be specified whether they should be packaged into RPM. What does that mean. If there are 4 directories in the%{buildroot} directory A, B, C and D, in the%files only specify a and B to be packaged into RPM, if the C and D with Exclude declaration is to error, if the declaration%{buildroot} does not exist in the file or directory will also error.

For%doc macros, all files following this macro are from the%{_builddir} directory, and the files specified by this macro will be installed into the/usr/share/doc/name-version/directory when the user installs RPM.
%changelog Phase This is the final phase, the change log for each time the main record is packaged. The standard format is:

Click (here) to collapse or open the * date + "%a%b%d%Y" Modify this version of the person's mailbox X.y.z-p-This change modifies those contents

Say so much, we combat. Many tutorials on the internet are the beginning of the Tomcat or Nigix, here I start with a simple MP3 decoding library Libmad, it into an RPM package, the following steps:

(Install if there is no rpmbuild command on your own system: Yum install rpm* rpm-build rpmdev*)
1, build the RPM of the compilation directory structure:

2, download Libmad source to the Rpmbuild/sources directory, you can download from http://downloads.sourceforge.net/mad/libmad-0.15.1b.tar.gz here.

3. Executing rpmdev-newspec-o libmad-0.15.1b.spec under the Rpmbuild/specs directory generates a template file named Libmad-0.15.1b.spec in the current directory. 4, the Libmad-0.15.1b.spec will be modified to look like the following:

5, in the Rpmbuild/specs directory to perform packaging compilation:

Click (here) to collapse or open RPMBUILD-BB Libmad-0.15.1b.spec

The resulting RPM package is as follows:

     because I am a 64-bit system, the compiled Libmad apply to centos6.0-64.      If we copy the Libmad source and spec files to the 32-bit system, then perform RPM packaging to see the results:
     results are as follows:

PostScript:
    about spec files, there are other features, such as what to do before and after installing the package, and what to do before uninstalling the package, including patching the source code, and exploring the children's shoes for which they are interested. At last, a complete set of spec file templates containing patching, installing and unloading features is given:

Click (here) to collapse or open name:           test version:requires:% Description ... #==================================spec head ====================================%prep%setup-q%patch   <==== is here to pack%build%configure make%{?_smp_mflags}%install rm-rf $RPM _build_root make install destdir= $RPM _bui Ld_root%clean rm-rf $RPM _build_root%files%defattr (-,root,root,-) to be packaged into the RPM package file list%doc%changelog #=================== ===============spec main ====================================%pre to do before installing or upgrading the software, such as stopping services, backing up related files, and so on. %post installation or upgrade after the completion of things to do, such as the implementation of Ldconfig refactoring Dynamic Library cache, start the service, and so on. %preun things to do before uninstalling the software, such as stopping related services, shutting down processes, and so on. %postun what to do after uninstalling the software, such as deleting backups, configuration files, and so on.