RPM Production Guide (2)

Article title: RPM Production Guide (2 ). Linux is a technology channel of the IT lab in China. Includes basic categories such as desktop applications, Linux system management, kernel research, embedded systems, and open source.
Evidence: Yu Yiqi and Zhao Jianli
　　
An RPM package description file can generate only one parent package or one sub-package, or one parent package and multiple sub-packages. By setting the sub-package option, you can use the standard "software name-sub-package name" for the generated sub-package, or use your own name for the generated sub-package. A sub-package is usually packaged by merging the files according to their purpose or type. As the preceding LZE description file is simple, it includes all files in the parent package. We can also classify files into sub-packages, such as lze-bin and lze-config) and instructions (lze-doc ). We can also separate only one configuration file sub-package (lze-config), and all other files are inserted into the parent package (lze ). Detailed classification helps you manage software packages, avoid unnecessary installation, and upgrade.
To create a sub-software package, you must describe the following:
1.% package:
Use this section to create a sub-package. Its name is controlled by the sub-package option. The sub-package option is "[-n] sub-package name". if-n is not selected, the generated sub-package file is "software name-sub-package name-version number-release number. system. when "-n" is selected, the generated sub-package file is "sub-package name-version number-release number. system. rpm ". The application format is:
% Package sub-package options
2. Summary
This field must be under % package, which defines the sub-package function introduction (in one sentence ). Format:
Summary: Introduction to sub-packages
3. Group
This field must be under % package and define the software category to which the sub-package belongs (for software categories, see < <精通rpm之五--查询篇> > ). Format:
Group: software type
4.% description:
The content of this description section is a more detailed sub-package function introduction, which is in the text form, the format is not required, can be any line break or segment. Format:
% Description sub-package options
... Introduces the sub-package function...
5.% files:
The content of this file segment is the list of files to be included in the sub-package. In the file list, a file occupies one row and multiple file modifiers can be used. (For details, see < <精通rpm之七--制作篇(上)> >)
The application format of the segment name is:
% Files sub-package option [-f file name]
Note: the sub-package option format used in the preceding % description and % files segments must be the same as that used in the % package. Otherwise, they do not define the same sub-package, an error will be reported during RPM check and exit. If % package name is defined, % description name must be used for the description segment name, and % files name must be used for the file segment name. % Description-n name cannot be used, and % files-n name cannot be used.
The sub-packages can also use seven optional functional segments, including % pre, % post, % preun, % postun, % triggerin, % triggerun, and % triggerpostun, because they can all use the sub-package options. When the sub-package option is used, their segment content is the script program used to manage the sub-software package. Note that the sub-package option format used by these segments must be the same as that used by the % package segment.
Use of conditional statements
In the software package description file, conditional statements can be flexibly used with no location restrictions. These statements are used to determine the current system and operating system. when the condition is true or false, RPM will reference the corresponding description.
Conditional statements have two formats:
1. {% ifarch, % ifnarch, % ifos, % ifnos} value 1 [value 2]...
Description
% Endif
Note: {} is one of the mandatory content. [] is optional. each value is separated by a space. % endif indicates that the condition statement ends.
The meaning of this statement is:
1) when % ifarch is used, it indicates that if the current system is a value of 1 or a value of 2..., the description is referenced.
2) when % ifnarch is used, it indicates that if the current system is not set to 1 or a value of 2..., the description is referenced.
3) when % ifos is used, the description is referenced if the current operating system is 1 or 2.
4) when % ifnos is used, it indicates that if the current operating system is not set to 1 or a value of 2..., the description is referenced.
If you want to add a file segment that is only applicable to the Linux system in the LZE package description file. lze and/etc/iSCSI. ime, you can add the following statement in the file segment:
% Ifarch iSCSI
/Etc/iSCSI. lze
/Etc/iSCSI. ime
% Endif
After this is done, if the current system is iSCSI, the RPM will add the two files during packaging.
2. {% ifarch, % ifnarch, % ifos, % ifnos} value 1 [value 2]...
Description 1
% Else
Description 2
% Endif
Note: {} is one of the mandatory content. [] is optional. values are separated by spaces. % else indicates another situation. % endif indicates that the condition statement ends.
The meaning of this statement is:
1) when % ifarch is used, it indicates that if the current system is a value of 1 or a value of 2..., the reference description content 1; otherwise, the reference description content 2.
2) when % ifnarch is used, it indicates that if the current system is not set to 1 or a value of 2..., the description 1 is referenced; otherwise, the description 2 is referenced.
3) when % ifos is used, it indicates that if the current operating system is set to 1 or a value of 2..., the description 1 is referenced; otherwise, the description 2 is referenced.
4) when % ifnos is used, it indicates that if the current operating system is not set to 1 or a value of 2..., the description 1 is referenced; otherwise, the description 2 is referenced.
To determine the LZE package Name based on the current operating system, you can use the following statement in the description file header to define the Name field:
% Ifos linux
Name: lzeforlinux
% Else
% Ifos aix
Name: lzeforaix
% Else
Name: lzeforothersys
% Endif
% Endif
The nested condition statement is used in this example. it indicates that if the operating system is linux, the software name is lzeforlinux. if the operating system is aix, the software name is lzeforaix, if not, the software name is lzeforothersys.
How to use a macro (macros) in the description file)
1. what is a macro?
Anyone who has learned the C language knows that macros are used to replace text. after macro names and macros are defined, all macro names in the file will be replaced by macros during preprocessing. Using macros can reduce the input amount of text and facilitate programmers. Using macros in the software package description file is also based on this purpose, but this macro is different from the macro definition format in C language.
2. macro definition
The macro definition format in the description file is:
% Define [(opts)]
Note: [] is optional. The macro name can contain letters, numbers, and underscores (_), and the minimum length is 3. Opts is one or more options, and each option is not separated. the option is in the form required by the getopt function, that is, the option is a single character. If an option requires a parameter, you need to add a colon (:) after this option (:). Is a macro, and the null characters around it will be deleted. The content of the macro must be on one line.
If no macro definition is available:
% Define aaa "This is my software"
For example, the macro definition with only one option is as follows:
% Define xxx (p: Z) echo % {-p: % {-p * }}% {-Z}
3. use of macros
Macro format:
% [Opt1] [opt2]... [arg1] [arg2]...
Or
% {} [Opt1] [opt2]... [arg1] [arg2]...
Note: [] can be included as an option; it is the macro name of the application, and the macro name can be included in {}; opt1, opt2... it must begin with a minus sign (-). If the option requires a parameter, you must provide an option parameter; arg1, arg2... is the macro parameter.
As defined above, the xxx macro can be used as follows:
% Xxx-p zhsoft hello world <
Br>
In this example, the xxx macro uses an option-p, zhsoft is the parameter of the-p option, and there are two macro parameters hello and world.
Note: it is best to change one more line when using a macro (that is, a blank line under the macro), because the macro does not wrap after expansion, so if there are not many line breaks, if there is any content in the following line, the extended macro content is merged with the content of the following line, which is very prone to errors. This is also one of the problems I found in RPM macros. There is another problem. if a macro exists on the comment line, the macro will also be extended. wrong! This is because annotations should be ignored, and macros do not need to be extended. Both of these issues need to be noticed by the RPM developers and solved.
4. macros for macros
The following special macros can be used in a macro: (macros in SHELL format)
1) % 0: indicates the macro name of the macro;
2) % *: all macro parameters;
3) % #: number of macro parameters;
4) % {-f}: indicates that if the macro uses the-f option, it indicates-f and its option parameters;
5) % {-f *}: indicates the-f parameter if the macro uses the-f option;
6) % {-f: X}: indicates that if the macro uses the-f option, it indicates X;
7) % {! -F: Y}: indicates that if the macro does not use the-f option, it indicates Y;
8) % 1, % 2,...: indicates macro parameter 1, parameter 2...
For example, when the xxx macro is executed in the preceding example, if the macro contains the above dedicated macro, the dedicated macro will be extended:
1) % 0 is extended to xxx;
2) % * extended to hello world;
3) % # extended to 2;
4) % {-p} is extended to-p zhsoft;
5) % {-p *} is extended to zhsoft;
6) % {-p: good} is extended to good;
7) % {! -Z: bad} is extended to bad (because the-Z option is not used in the xxx macro)
8) % 1 is hello, % 2 is world, and no other parameters exist.
5. built-in macros
The built-in macros of the system can be divided into the following three types:
5.1 Definition class
1) % define...: defines a macro. (originally, % define is also a macro)
2) % undefine...: cancels a macro. (after the macro is canceled, the description file below this statement cannot use this macro any more. even if it is used, the macro will not be extended)
5.2 debugging
1) % trace: prints debugging information before and after macro expansion;
2) % dump: prints the macro (macro name and macro) of the activity );
3) % {echo:...}: Print... to the standard error device;
4) % {warn:...}: Print... to the standard error device;
5) % {error:...}: Print... to the standard error device and return the BADSPEC value;
5.3 Special classes
The default values of these macros are usually stored in the/usr/lib/rpm/macros file. you can edit the. rpmmacros File (~ /. Rpmmacros), you can redefine this type of macro and change its default value for RPM to use its own definition during software package creation, installation, and query.
The definition format of these macros is:
%
Note: The macro name is macro.
1) % packager, % vendor, % distribution:
These three macros are used to define the default domain values of the three optional fields in the description File: Packager, Vendor, and Distribution. that is, if any of the three fields is not defined in the description file, and its corresponding macro is defined, RPM will use its corresponding macro.
For example, my ~ The/. rpmmacros file contains the following three lines:
% Vendor vertical and horizontal software production center
% Packager Yu Yiqi
% Distribution Xiao Zhao '2001
In this way, the three fields no longer need to be defined in the software package description file. during the query, the Packager and the Vendor) and the release version (Distribution.
2) % buildroot, % _ provides:
These two macros define the root directory used for package creation and the features provided by the package. It