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 files, which are LPMtool specification files (specfiles). files are existing source package files when the --rebuild or the --resign option is specified, or source code tarballs when the --srcbuild option is specified. Multiple files may be specified, lpbuild builds all files specified on the command line.


--arch platform

Process the specification files targeting platform, instead of the default hardware platform.

--define name=value=

Set macro name to value, before processing the specification file.


Rebuild applications that were previously built by lpbuild. files are previously-created source packages, and not specfiles.


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.lpspec from each file, 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.

-o directory

Create binary package files, name-version-release.arch.lp, and source package files, name-version-release.src.lp, in directory, instead of the current directory.

-O 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.

--repository 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.

-s 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.


The full description of the lpbuild command is too long to be included in this manual page. See the LPMtool manual for more information.