One or more package declaration section follow the build header. Each package declaration begins with a “%package” line. “%package”, by itself, declares the main package. Subpackages are declared by giving the name of the subpackage: “%package doc” declares a subpackage named “doc”.
Each package declaration begins with an optional “Header: value” list, where possible values of “Header:” described below. A blank line follows the last header, then the human-readable description of the package.
The package description is, by convention, HTML text. Note that blank lines do not introduce a paragraph breaks. Paragraph breaks must be introduced by an explicit “<p>” HTML tag.
The “Header: value” lines in the package declaration section complement the ones in the build header section, except that they only apply to the package, or the subpackage. Different subpackages may have different “Header: value” lines. All following “Header: value” lines are optional, and a blank line is still required even if no “Header: value” lines are present. See Section 2, “Resources” for a description of the following resources:
list
Add list to the list of resources required
by this package
(see “Required resources”).
LPMtool automatically determines most resources required by a package,
such as shared libraries and Perl modules.
An explicit list is needed only when it is
necessary to explicitly add resources to
the automatically-generated required resource list.
list
Add list to the list of resources provided
by this package
(see “Provided resources”).
LPMtool automatically determines most resources provided by a package,
such as shared libraries and Perl modules.
An explicit list is needed only when it is
necessary to explicitly add resources to
the automatically-generated provided resource list.
list
list is a list of resources this package conflicts
with
(see “Conflicting resources”).
This is in addition to the automatically generated resource conflict
list.
list
list is a list of resources superceded by
this package
(see “Superceded resources”).
LPMtool automatically adds the “name(arch)<version-release”
resource by default, unless disabled by the
“NoAutoSupercedes:” (see below).
list
list is a list of resources obsoleted by
this package
(see “Obsoleted resources”).
list
list is a list of resources updated by
this package
(see “Updated resources”).
LPMtool automatically adds the “name(arch)<version-release”
resource by default, unless disabled by the
“NoAutoUpdates:” (see below).
list
list is a list of resources extended by
this package
(see “Extended resources”).
Extended resources are typically used by packages that contain optional kernel modules. Consider the following example:
...
%package
Requires: %{__name}-kmdl
...
%package kmdl-2.6.15-0.1
Provides: %{__name}-kmdl
Extends: kernel=2.6.15-0.1
Updates: kernel-2.6.15-0.1
...
Building this specfile creates the
%{__name}-kmdl-2.6.15-0.1kmdl packages can be
created for other kernel versions, and all packages are installed into
the application's repository. All kmdl packages
have the %{__name}-kmdl%{__name}-kmdlkmdl packages, but
the extended resource in each kmdl package will exclude it
from installation unless the corresponding version of the kernel package is
already installed.
When a new kernel version is installed, the corresponding
kmdl subpackage needs to be built and added to the
application's repository. Subsequently, the lpm --update
looks for all available updates. The “Updates” header in the
new kmdl subpackage results in the subpackage getting
installed.
Here's an example of a
specfile that
packages kernel modules similar to the way they're packaged
in Fedora Core:
%if %{!?kver}
%{expand: %%define kver %(uname -r)}
%endif
%{expand: %%define kverpkg %(echo 'kernel=%{kver}' | sed 's/kernel=\(.*\)smp/kernel-smp=\1/')}
...
BuildRequires: %(echo %{kverpkg} | sed 's/=/-devel=/')
...
%package
Requires: %{__name}-kmdl
...
%package kmdl-%{kver}
Provides: %{__name}-kmdl
Requires: %{kverpkg}
Extends: %{kverpkg}
Updates: %{kverpkg}
...
The kmdl subpackage usually has additional required and
provided resources.
“lpbuild filename.lpspec”
sets kver to the version and release of the running kernel,
by default. For other kernel versions, specify the
“--define kver=version”
option to lpbuild, where version
must match, exactly, the name of the kernel's subdirectory in
/lib/modules.
Fedora packages SMP kernels are named
“kernel-smp-version-release”,
and they install
/lib/modules/
(together with other things).
version-releasekverpkg gets set to
“kernel=version-release”
or
“kernel-smp=version-release”,
as appropriate, and that's used to define the updated, and the extended,
resource settings.
The presence of this line prevents the automatic
inclusion of the following resources in each
package “name”:
Provides: release-name(arch)=labelUpdates: release-name(arch)!=labelSupercedes: release-name(arch)!=label
“label” is a fixed identifier for
the distribution system's platform.
The presence of this line turns off the automatically-generated default list of required resources. All required resources (if any) must appear in “Requires:”.
The presence of this line turns off the automatically-generated default list of provided resources. All provided resources (if any) must appear in “Provides:”.
Turn off automatic generation of required Python modules. See “Section 3.1, “Python dependency tracking”” for more information.
This is implied, when “NoAutoReq: 1” is present. It is not necessary to specify this when “NoAutoReq: 1” is also specified.
Turn off automatic generation of provided Python modules. See “Section 3.1, “Python dependency tracking”” for more information.
This is implied, when “NoAutoProv: 1” is present. It is not necessary to specify this when “NoAutoProv: 1” is also specified.
The presence of this line turns off the automatic addition of “name(arch)<version-release” to the list of resources superceded by this package.
The presence of this line turns off the automatic addition of “name(arch)<version-release” to the list of resources updated by this package.
Each file installed by the package results in an implicit “filename=checksum” provided resource, and a “filename!=checksum” conflicting resource. These resources will always be present. The “NoAutoProv: 1” and “NoAutoReq: 1” headers cannot suppress these resources (but it does suppress the automatically-generated provided resources based on the names of shared libraries and Perl modules installed by the package).
Furthermore, the required resources “/etc/passwd” and
“/etc/group” cannot be suppressed either (if they are required).
See Section 2.1, “Required resources: /etc/passwd, /etc/group” for more information on these resources.
In nearly all situations LPMtool will automatically compute a package's dependencies: which resources the package requires, and which resources the package provides, which might be required by other packages. The usual kinds of resources are shared libraries and Perl modules. LPMtool analyzes which shared libraries are loaded by each binary program in a package, and specifies the names of those shared libraries as required resources. If a package installs its own shared libraries, their names get recorded as provided resource.
LPMtool uses similar logic with Perl modules. Perl's syntax is receptive to easy parsing, and it's usually trivial to determine the name of Perl packages contained in a Perl script, and names of other packages a Perl script uses.
LPMtool tries to do the same with Python scripts. Python's syntax, however, is more complex and this not as exact of a science as it is with Perl.
It is not always possible to accurately reverse-engineer the full hierarchical name of a Python module, based on its filename alone. Furthermore, there are a number of ways a Python module can import other modules. To complicate matters even further, any shared library is a potential Python module. What really happens is that LPMtool checks the symbol table of shared libraries installed by the package, and tries to figure out if a shared library is a Python extension based on its symbols.
Then, when LPMtool needs to determine what other modules a particular
Python module
requires, LPMtool takes the bull by the horn, starts a
Python intepreter,
and tries to import the module, and looks at what other baggage got imported
by that action.
The presence of the
“NoAutoProvPython: 1” and
“NoAutoReqPython: 1” headers turns this off.
“NoAutoReqPython: 1”
should be used if
importing a package's Python module
(or a Python extension) during the
packaging process will have unwanted consequences.
“NoAutoProvPython: 1” should be used when
LPMtool's algorithm for computing a module name does not work for a particular
package.
If needed, the “python(name)”
required and provided resources can always be manually added to the package's
header.
Specifying “NoAutoProvPython: 1” and “NoAutoReqPython: 1” turns off only automatic generation of Python dependencies. Automatic generation of other kinds of dependencies (regular shared libraries, Perl modules) is not affected.
The default lpm configuration always creates a subpackage called “debuginfo”. Do not declare this package explicitly, it will be created by default. lpm automatically removes debugging data from all binary programs and libraries before creating a package. The debugging data is not needed when running the programs, and removing the debugging data reduces the amount of disk space required by a package.
The “debuginfo” subpackage contains all binaries and programs installed by the main package and all other subpackages, but with the debugging data preserved, and intact. The “debuginfo” subpackage is useful for debugging core dumps, and other diagnostic purposes.
The creation of the “debuginfo” subpackage may be suppressed
by setting the __create_debugpackage macro to
“0”, either by passing the option
“--define __create_debugpackage=0” to lpbuild,
or by setting this macro in the
specfile.
This macro must be set in the build header portion of the
specfile, before all other package
declaration.