A “package” is a a single file that contains everything that's needed to install a particular application. All information about the application, such as what files it installs and what other software it needs in order to work, are contained in this single package file.
Package files use the following naming convention:
.
Example: name
-version
-release
.arch
.lplinux-2.6.10-1.i386.lp
.
“name
” is the application's short,
brief name, such as
“linux” for the Linux kernel, or
“emacs” for the Emacs text editor.
“version
”
is the application's announced version, such as
version “2.6.10” of the Linux kernel.
“release
”
is the errata release number for this version of the application.
The initial package that contains, for example, release 2.6.10 of the Linux
kernel will carry a release number of
1
.
If some kind of a packaging error is uncovered, a corrected package would
carry a release number of 2
:
linux-2.6.10-2.i386.lp
.
Package version and release numbers may follow any meaningful, sensible,
format. LPMtool is capable of understanding most common version and release
number formats.
See Section 1.2, “Comparing package versions and releases” for more information.
Very large applications may consist of more than one package file:
the main application package, and additional, optional, subpackages.
The naming convention for subpackages is
.
Example: mainname
-subpackagename
-version
-release
.arch
.lplinux-doc-2.6.10-1.i386.lp
.
“arch
”
specifies the package file's hardware platform.
An i386
package will contain programs for
the Intel 32-bit platform family; x86_64
designates applications built for AMD
Opteron™ CPUs.
LPMtool accepts an i386
package for installation on any
compatible platform, from the original Intel 386 CPU, up to
Pentium II™ and beyond.
Opteron™s are also capable of running
i386
code, if all 32 bit libraries the
application needs are also present.
The converse is not true. x86_64
packages cannot be
installed on a mere Intel 386 CPU.
noarch
specifies that the
package's contents are platform-independent (such as plain text documentation).
noarch
packages may be installed on any platform.
The lpbuild command takes the source code for an application, compiles it, and creates package and subpackage files. A “build specifications” file, or “specfile” for short, instructs lpbuild how to go about doing that. The “specfile” is a text file that provides all information to lpbuild, such as the name and the version of the application, the files with the source code, and the script to build the application and create its install image.
See Chapter 7, Building packages
for more information about the
specfile
.
lpbuild
reads the
specfile
,
and eventually produces the application package file (and any additional
subpackage files), which can be installed by
lpm.
lpbuild also assembles a “source package”
file, named
.
The packaging process for most applications needs a number of files,
such as: the
name
-version
-release
.src.lpspecfile
itself;
one or more tarballs with the source code;
any patches; and perhaps other miscellaneous files.
The “.src.lp” source package file contains all of the
files required to build the application.
If it becomes necessary to rebuild the application at some later point,
the source package will contain all the required information.
lpbuild
can rebuild the application given only the
source package:
lpbuild will pull the
specfile
, and all the other source files,
from the source package file, then proceed with the build process.
See Chapter 8, Publishing packages on a web site and Chapter 9, Mirrors and proxies for a primer on publishing package files on the web. See Chapter 12, Manual Pages for the lpbuild and lpm command reference. See Chapter 13, LPMtool Objects for an in-depth description of LPMtool's internal data structures (including Section 7, “Packages”, a technical description of the structure of a package file).