lpbuild — Build LPMtool packages
lpbuild [--arch platform] [--define name=value...] [-v] [-Q] [-s section] [--rebuild] [--srcbuild] [--sign] [-o directory] [-O directory] [--repository directory] file...
lpbuild --resign filename...
lpbuild [--sign] [--name "description"] [--authkey "key"] --mkmeta metafile.lp package...
lpbuild [--sign] [--name "description"] [--authkey "key"] --mkmeta -l metafile.lp package name...
lpbuild takes the source code for an application, compiles it, and creates one or more installable package files, which can be installed later by lpm.
lpbuild
builds filespecfiles).
file--rebuild
or the --resign option
is specified, or source code tarballs when the --srcbuild
option is specified.
Multiple filefile
platform
Process the specification files
targeting “platform”,
instead of the default hardware platform.
name=value=
Set macro name to
“value”, before processing the
specification file.
Rebuild applications that were previously built by lpbuild.
filespecfiles.
Build packages directly from source code tarballs.
This option makes it possible to distribute source code tarballs that can
be directly converted into installable packages with a single command.
The specfile must be included in the source code
tarball, with the file extension .lpspec.
LPMtool extracts the first file named
filename.lpspecfile, and uses it
to build the package.
For this to work, the source code tarball must contain everything needed to
build the application.
The specfile must specify a single source code
tarball, with a matching filename, and no additional tarballs or
patches.
directory
Create binary package files,
name-version-release.arch.lpname-version-release.src.lpdirectory, instead of the
current directory.
directory
Create source packages in directory.
By default, the source packages are created in the directory specified by
the -o option.
Use this option to specify a different output directory for source packages
(the binary packages will still be created in the -o
directory).
Source package files are not created when
--rebuild is specified.
The binary package files are rebuilt from the
source package files specified on the command line.
directory
Create source and
binary packages in directory, which is
a primary repository created by the
lpm --init primary command (see
lpm(1)).
This option is equivalent to
“-o directory/distribution/packages
-O directory/distribution/sources
--sign”
(all packages in the primary repository must be signed).
This option can also be set by placing
%define __buildrepository directory
in $HOME/.lpsetup.
See Section 13.4, “Predefined macros” in LPMtool's documentation for
more information.
Sign the package files with GPG.
The package files are signed with the default key.
lpbuild needs to be invoked from an interactive shell.
lpbuild issues a terminal prompt for the default key's
GPG passphrase.
Press Enter alone if the default key is not protected by
a passphrase.
The passphrase prompt is not issued unless the standard input comes from
a terminal window.
Non-interactive scripts may use
--sign and
--resign
only if the default GPG key is not protected by a
passphrase.
Add a GPG signature to existing package files.
--sign is an optional build parameter.
If package files were built without using
--sign, the package files can be signed later with
--resign.
A package file can have only one signature.
The --resign option replaces any existing signature with the
new signature.
Generate additional progress indication messages while building packages.
Quiet mode. Generate only the minimum amount of messages.
section
Run only a portion of the build script named
“section”.
Normally
specfile's
entire build script runs from start to finish, and
lpbuild
creates the package files when the build script succesfully finishes.
The -s option is used when developing a new build script.
It runs only the portion of the build script specified by
section, without creating any package files.
section needs only to match the first part of
the portion of the build script.
Example: “-ss” executes the “setup” portion of
the build script; and “-sc” executes the
portion called “compile”.
A “metapackage” is a small file that contains a URL of a package repository, its keys, and a list of package names to install. The metapackage file is “installed” by the lpm(1) command. lpm processes the metapackage file by registering the package repository, then downloading and installing the list of packages specified by the metapackage.
Metapackages are a convenient mechanism for providing a link from a website that automatically downloads and installs software, provided that LPMtool's graphical utility is integrated into the Gnome desktop (well, semi-automatically, since LPMtool will inform the user what's about to happen, and request a confirmation). See LPMtool's installation manual for more information on installing LPMtool's graphical utility.
The “--mkmeta” option creates
metafile.lp (the first filename after the options)
from one or more package, which follow the
metafile.lp.
The packages must already be created (with lpbuild, of
course), and the package must include the “Repository:” header
that gives the package's repository URL and
GPG keys.
See the
“Build header” section in
LPMtool's manual for more information on the “Repository:”
header.
lpbuild reads the repository information from the
package files.
Furthermore, the names of packages placed in the metapackage are also
taken from the package files.
This is usually somewhat limiting.
For example, if the package file contains an application named
“gizmolib” for an i386 platform, version
2/release 1, lpbuild records the package name.
“gizmolib(i386)-2-1”.
This means that installing the metapackage will always install this specific
version and release of “gizmolib”.
The -l option adds more flexibility.
-l requires that exactly one existing package file must
be specified.
Only the repository information is copied from the existing package file into
the new metapackage.
The list of actual packages follows the package file, and is taken verbatim.
Example:
lpbuild --mkmeta gizmolib.lp gizmolib-2-1.i386.lp gizmolib gizmolib-devel
This command creates gizmolib.lp, a metapackage.
The metapackage's repository
URL is taken from an existing package file,
gizmolib-2-1.i386.lp, and the metapackage contains
two packages called “gizmolib” and “gizmolib-devel”.
When this metapackage gets installed by lpm,
they get interpreted as the latest available version/release of the
“gizmolib” and “gizmolib-devel” packages, for
lpm's installed hardware platform.
It goes without saying that, hopefully, these packages were built for lpm's installed hardware platform.
This means that a new gizmolib.lp does not need to be
made after an updated version of its component packages are added to the
repository.
The metapackage always installes the latest version.
The --name option gives a descriptive name for the
software packages installed by the metapackage.
This name gets shown when lpm asks for permission to install the
metapackage.
The --authkey gives the package repository's authorization
key.
This is used with restricted access repositories.
See LPMtool's manual for more information on restricted access
repositories.
--authkey is typically used with web-based applications
that construct a metapackage file with the right authorization key on the
fly, which then gets downloaded by the client.
The metapackage file may also be signed, with the --sign
option.
This option is available, but is of somewhat limited benefit.
The metapackage files are normally placed on a web site, and are downloaded
and installed without having their signatures checked.
The authenticity of the metapackage is verified by inspecting the
URL of the repository shown by lpm before registering
its package repository.
Where possible, metapackages should be published via SSL,
to take advantage of SSL certificates' domain name
verification.
The web server must be configured to return the MIME
type of application/x-lpm-package for LPMtool
metapackages, which is bound to LPMtool's graphical utility.
It is possible for an lpm package to specify two or more repository URLs. All specified URLs will get added to the metapackage.