lpm — LPMtool is a Package Management tool


Installing, updating, adding, and removing packages

lpm [-i] | [-u] | [-a] [[-f] | [--force]] [[-t] | [--test]] [-v] [-Q] file...

lpm [-e] [[-f] | [--force]] [[-t] | [--test]] [-v] [-Q] package...

Querying package resources, scripts, and triggers

lpm -q [-i] [--repos] [--repokeys] [-l] [-v] [-Q] [-a] [-p] package...

lpm -q --requires | --provides | --conflicts | --obsoletes | --supercedes | --updates [--all] [-a] [-p] package...

lpm -q --whatrequires | --whatprovides | --whatconflicts | --whatupdates resource...

lpm -q -f file...

lpm -q --scripts | --triggers | --verify [-a] [-p] package...

Checking GPG signatures

lpm --check [-v] [-Q] file...

Verifying packages

lpm --verify package...

Repairing a corrupted package database

lpm --repair | --clearlock [-v] [-Q]

Primary repositories

lpm --init primary directory keyfile

lpm --set-name directory name

lpm -q --distribution | --distribution-name

lpm --set-refresh | --set-full-refresh directory interval

lpm --updatekeys directory keyfile

lpm --sync [--force] directory

lpm --erase [--sync] directory file...

lpm --set-url directory [url]

Remote repositories

lpm --init remote [--authkey key] directory url

lpm -q -r directory options...

lpm --sync [--force] [--purge] directory

lpm --repair directory

lpm --get directory package...

lpm --getsrc directory filename...

lpm --authkey directory [key]

Registered remote repositories

lpm --remote --list

lpm --remote --add url

lpm --remote --add -p package

lpm --remote --remove n

lpm --sync --all [--purge]

lpm --update [--check]


lpm installs, removes, and updates software packages. A package comes in a form of a specially-formatted single file. This monolithic file contains an archive of all the individual files and scripts that make up a software application.

Installing, updating, adding, and removing packages

The -i option installs a new package, that's not already installed. -u installs an update, a newer version of a package that's already installed. The older version is removed (there may be rare exceptions for some packages, such as kernel packages which do not remove older versions, even if installed in update mode). The -u does nothing if a newer version of the package is already installed, or if an older version of the package is not already installed. The -a option (add) is a combination of -u and -i. If an older version of the package is already installed, -a updates it, otherwise the package is added as a new install. Finally, -e removes a currently installed package.

Before installing any package, lpm automatically checks to make sure that all prerequisite requirements are present. Most packages require that other packages should be installed first. If they are not, lpm will try to download the other, required packages. The packages will be downloaded automatically from previously-registered software repositories (see Registered remote repositories below). lpm will ask for permission to register any new software repository, before downloading packages from them, for the first time.

On RPM systems that use yum to install RPM packages, if lpm cannot find some required resources, it will use yum to search for RPM packages with the required resources. lpm runs yum to install the required RPM package, then mklpmcompat(1) to synchronize the contents of the RPM and lpm universes. mklpmcompat will take some time to complete. lpm uses yum only if mklpmcompat is also installed by the lpmtool-compat package.


mklpmcompat should have been used already to synchronize the RPM and lpm universes, so that lpm knows before it begins installing anything what's already installed by RPM, and vice-versa.


lpm sets the ownership of installed files from the contents of /etc/passwd and /etc/group. Some systems may be configured to use external databases, such as LDAP or NIS for mapping usernames and groupnames to numeric userids and groupids. lpm checks only the contents of /etc/passwd and /etc/group, ignoring anything in /etc/nsswitch.conf.

Systems that use external databases for managing user accounts should still have system accounts (accounts and groups with userid/groupids below 100) listed in /etc/passwd and /etc/group.

After installing all packages, lpm checks if any packages specify a package repository URL (for updates) that has not been registered. When lpm finds an URL that's not registered, LPMtool asks for permission to register it, in order to allow automatic downloads of updated packages in the future. This is optional. The package repository can always be registered later, using --remote --add -p.

lpm automatically removes registered package repositories after uninstalling the last package that references the repository.

The -i, -u, and -a options take a list of files. Each file contains a single package. The files usually use the following naming convention: name-version-release.arch.lp. name is the application's name. Sub-packages (optional component packages that may be installed in addition to the main package file) use name-subpackagename for their name. version is the application's version. release is the errata release of this version. arch indicates what hardware platform the package is for, such as i386 for Intel 32-bit platform CPU family, or x86_64 for the AMD Opteron™ CPU family. The architecture noarch specifies a platform-independent package, such as text documentation.

The -i, -u, and the -a options also take metapackages. Exactly one file, the metapackage file, may be specified. A metapackage file contains a URL of a package repository, and names of one or more packages. lpm registeres the repository and downloads and installs the specified list of packages. By convention, only the -a option is used with metapackages. The graphical lpm utility automatically uses the -a option to install metapackages. The -i, -u options are only available with the lpm command.

This is a general overview of the -i, -u and -a options. Each package file contains specific instructions lpm follows when installing or updating the package. For example: it's possible that installing or updating a package automatically uninstalls some other package which is now obsolete. This happens automatically when the package file is processed.

The -i option reports an error if the package is already installed. The -u option ignores packages that are already installed (or if a newer version of the package is already installed), and updates the remaining packages.

The -u option may also accept a name of a remote repository directory instead of a package filename. Remote repositories are described later. Specifying a name of a remote repository directory is the same thing as specifying the name of every package in the remote repository. The net effect is to update existing packages to the newer versions from the remote repository directory, if they are available.

The -a and the -i options also accept a remote repository directory, but the end result is less desirable. Essentially, an attempt will be made to install all packages in the repository, which is rarely useful, especially if the remote repository holds packages for multiple, incompatible, architectures.

lpm takes care of automatically downloading packages from the remote repository, as needed. When a passing a name to the -u option (or the -a or -i options) that doesn't exist as a file, or a directory, it gets intepreted as a name of a package. lpm searches all registered remote repositories (described later) for this package, and installs it (or updates it, or adds it). The name of the package can be specified using any format that's understood by the -e option.

The -e option uninstalls packages. This option takes a list of package names in any one of the following formats:


Uninstall any installed version and errata releases of application name.


Uninstall any errata release of the given application version.


Uninstall a specific errata release.

In all cases name may be optionally followed by (arch) to remove only the package for the given architecture. Example: kernel(i686). Use quotes or apostrophes on the command line, because the parenthesis are special shell matacharacters which must be escaped. It is possible to have the same application, version, and release installed for different architectures. Each architecture is a separate package, and normally -e refuses to process a name that matches multiple packages, as precaution. A specific architecture must be named, in this manner, when different packages with the same name, but different architectures, are installed. Without a specified architecture, the package name by itself will match multiple packages, and fail for that reason.

Before installing, updating, or removing anything, lpm checks for resource conflicts. Several conflicts are checked for, such as: the new package would overwrite a file installed by some other package, or a new package needs another package to be installed first, or if a package to be removed is required by another package, for some reason. A resource conflict stops everything. Nothing gets installed, updated, or uninstalled, even if only one package -- in the list of packages -- has a problem.

The -f (or --force) option instructs lpm to ignore any resource conflicts, and proceed. Do NOT use -f unless the consequences are fully understood. -f does NOT fix the problem. The problem is real, and must be fixed in some other way. This option is meant to be used as a temporary solution, until a real one is found.

The -t (or --test) option checks for any resource conflicts, but does not actually install, update, or remove anything.

Installing or uninstalling large packages may take some time, and lpm displays appropriate messages as it makes progress. The -v option generates even more messages. The -Q turns on quiet mode, which turns off all but the most critical messages.

Querying package resources, scripts, and triggers

-q queries information about packages which are already installed. Each package may be specified as either: name - all versions and releases of application name; name-release - all releases of application name, version release; name-release-version - a specific version and release of name. When there is more than one package with the same name, version, and release, but different architectures are installed, append (arch) to limit the query to a specific architecture, instead of all architectures. Single quotes must be used around id in order to prevent the shell from trying to interpret the parenthesis.

-p specifies that packages are package files. lpm reads the package information from these files, instead of the installed package database.

Alternatively, the -a option queries information from all installed packages.

The default output is the full name of all matching packages: name(arch)-version-release. The -i option displays complete package information. The -l option lists all files contained in the package, like the ls command. Specify -v in addition to -l to increase the verbosity, resulting in output similar to ls -l.

The --requires, --provides, --conflicts, --obsoletes, --supercedes and --updates options display the corresponding list of resources from a package. package specifies the package's name. --scripts displays the scripts that run when the package is installed or uninstalled, and --triggers displays scripts from this package which are triggered by installation or uninstallation of other packages.

The --repos option show the URL of a package's repository, if any. The --repokeys option extracts the package's repository's PGP key.

The -p option reads the resources or scripts from a package file; package must be a name of a package file.

Because of how LPMtool works, every physical file installed by a package is included as one of package's provided and conflicting resources (this mechanism is used to prevent files from one package from getting accidentally overwritten by other packages). These resources are suppressed by default. The --all option includes those resources in the displayed list.

--whatrequires, --whatprovides, --whatconflicts, and --whatupdates options search for any installed package that has a matching resource. Example: lpm -q --whatrequires /bin/sh lists packages that contain shell scripts (or at least the ones that specify /bin/sh as their interpreter).

Finally, the -f option displays which package installed this file.

Checking GPG signatures

The --check option checks the GPG signature of each package file.

Verifying packages

LPMtool keeps track of every file installed by a package. For each file LPMtool records the file's timestamp, file permissions, ownership, checksum, and several other properties. The --verify option compares each file in a package against its saved information. --verify lists all files that were changed since their package was installed. Each line contains a seven character string that shows what file attributes have changed; the file attributes may be followed by c and/or g, then the file's name. The presence of c means that the file is marked as a configuration file. The presence of g means that the file was listed as part of the package, but was not actually installed. This is usually the case with runtime-generated log files. There may be a good reason why files tagged with c and g were changed after installation.

The seven character string shows which one of the following file attributes has changed:


The file's size has changed.


The file's permission mode settings have changed.


The file's MD5 checksum (the file's contents) have changed.


The file's type has changed (socket, FIFO, block or character device).


The file's user ownership has changed.


The file's group ownership has changed.


The file's modification timestamp has changed.

A . in the place of each character indicates that the corresponding file attributes match. A ? indicates that the corresponding file attributes cannot be compared (file's permissions prevent LPMtool from opening the file, for example).

lpm terminates with an exit code of 1 if any file differences were found. A package may also have an optional verification script. lpm terminates with an exit code of 10 if the package's custom verification script fails. An exit code of 0 indicates that no differences were found, and lpm produced no output, and the package's custom verification script gave the green light.

Repairing a corrupted package database

Information about the installed packages is saved in a collection of database files. lpm takes special care to make sure that the database files are updated correctly, but, Murphy's law being what it is, an inopportune crash might result in a corrupted database file. The --repair option rebuilds the internal database files. This is a lengthy process which requires plenty of RAM.

Use the following process to salvage the system package database.

  1. Run lpm -q -a and make sure that it completes successfully, listing all identifiable packages. If it hangs, run lpm --clearlock and try again.


    It may take some time for a large package to appear in the output from lpm -q -a. Specifically, the lpmcompat package tends to be very large, and take a minute or so to come up. Be sure to wait at least a few minutes before giving up.

  2. If lpm -q -a reports an error, it means that a package manifest file is bad. Obtain the package's name from the error message. Look in the package database's directory (usually /usr/local/var/lpm or /var/lpm). Look in the manifests subdirectory, which contains numbered subdirectories that hold the package manifest files.

    Find the numbered subdirectory with the bad package manifest file, and delete the file. Run lpm -q -a to look for any other bad package manifest.

  3. Once lpm -q -a completes successfully, run lpm --repair.

Primary repositories

A primary repository is a directory, usually a directory on a web server, where package files are distributed for publication. The --init primary option creates a new empty primary repository directory. This directory can be directly published over the web. An HTTP 1.1 server, such as a modern version of Apache, will give the best results.

keyfile is a file with exported GPG keys. GPG keys verify the integrity of all downloaded packages from the primary repository.

keyfile must be created by gpg --export --armor (which exports all public keys from the keyfile, use additional gpg options to export only specific public keys).

keyfile may have multiple keys. One of the keys must be the default GPG secret key. Every package in the primary repository must be signed by one of the keys (different packages may be signed by different keys, as long as every one of them is in the keyfile).

The --init primary option prompts for default secret key's passphrase, signs the keyfile, and installs it in the directory.

Press Enter if the default secret key is not protected by a passphrase. The default secret key must not be passphrase-protected when running lpm from a batch script that's not connected to a terminal, because no prompt will be issued.

The --set-name option sets a brief, one sentence description of the package repository. This command should be used immediately after creating a new primary repository.

Use the --updatekeys option to install a new keyfile, replacing the existing one. Note, however, that the key used to sign the keyfile must be present in both the old and the new keyfile, in order for the new keyfile's signature to validate for everyone who's downloading from the primary repository. The new keyfile should also remain in place long enough for everyone to have the opportunity to download it and get the new keys.

The refresh interval is how often the primary repository is checked for new packages. Initially, the primary repository's refresh interval is set to 23 hours, in anticipation of a daily job that gets kicked off at the same time. A refresh interval of an even 24 hours will not work reliably, it must always be slightly less than the anticipated check interval (an hour's margin is probably an overkill, though). The internal timestamp gets updated at the end of the process that checks for new packages. That takes a few seconds, at least. If the refresh interval was an even 24 hours, the next day's job will get skipped because when the job kicks off the timestamp will be less than 24 hours old. Close doesn't count.

Use --set-refresh interval to set a different interval (bearing the above caveat in mind), which can be specified as:


Set the refresh interval to n minutes.


Set the refresh interval to n hours.


Set the refresh interval to n days.

Use --set-full-refresh interval to set how often old package information gets purged from remote repository directories (see Remote Repositories, below). For reasons described in the Remote Repositories section, when a package gets removed from a primary repository, the package information does not get purged immediately from the remote repositories which previously downloaded the package information. If not specified, the full refresh interval is ten times the default refresh interval. Only when the primary repository's contents remain unchanged for the full refresh interval, will the deleted packages' information get purged from the remote repositories.


The primary repository's maintainer should consider two factors:

  • How often should lpm check for new packages in the primary repository.

  • How often the primary repository gets updated, on average.

The two are not necessarily the same. Take a typical package repository that, perhaps, gets updated once a week, on average. It makes sense to set the default refresh interval to one day, and a full refresh interval to five days. If the default refresh interval is one week, the after new packages are added to the repository it can still take another week before everyone gets them. A one day default refresh interval makes more sense. A full refresh interval that's slightly less than the average rate of changes to the repository makes sure that obsolete package data gets perioducally purged, in an orderly manner.


Setting similar intervals for the default and full refresh intervals results in the increased load on the primary repository, because lpm will keep downloading, needlessly, the full list of available packages. The full refresh interval must be at least 2-3 times longer than the default refresh interval.

Synchronizing the primary repository

The primary repository contains a single subdirectory whose name is based on the version of the system distribution LPMtool is running on, such as fc2.i386 for the i386 version of Fedora Core 2. In complex, mixed environments, multiple subdirectories will exist and contain LPMtool packages for different distribution labels. --init primary creates a new primary repository directory and the appropriate distribution directory. Running LPMtool built for a different distribution, and giving it the name of an existing primary repository directory, creates a new distribution subdirectory.

Use -q --distribution to display the distribution label lpm uses. The distribution label consists of two half, the second half is the hardware platform. Use -q --distribution-name to display the first half of the label, without the hardware platform portion.

In the distribution subdirectory itself, the packages subdirectory holds the binary packages, and the sources subdirectory holds the source packages. Package files may be added to these directories using any mechanism, but the --sync option must be used afterwards. Clients that try to refresh the package list will not be aware of any changes until the --sync option runs.


All primary repository commands, --sync and others, run against the current distribution subdirectory only, however the lpm command always takes the name of the primary repository directory on the command line, not the distribution subdirectory's. Similarly, when providing URLs to the lpm command, the primary repository's URL must be given, not the distribution-based subdirectory's.

The --sync command reads all package files, then updates all the relevant indices and metadata. Each package file is read, and checked to make sure it has a valid checksum. Any file in either the packages or the sources directory that's not a package file with a good checksum will be removed. To prevent race conditions, --sync ignores apparently corrupted files that are less than an hour old (somebody else might be in the middle of copying this file into the primary repository).

--sync does nothing if LPMtool thinks the repository directory has not changed. Specify --force to force LPMtool to rebuild the metadata even if LPMtool doesn't think it needs to do it. This may be required to fix minor corruption.

Removing packages from the primary repository

It is always possible to remove package files manually from a primary repository, then using --sync to update the repository's index. The --erase option is a convenient way to remove all package files that were built from the same source package.

Each file may be either a source package, or any package file (the main package or any subpackage) built from the source package. LPMtool removes all package files, with the same version and release, that were built from the source package. Specify the --sync option to update the primary repository's metadata indices after the files are removed (otherwise the files will be removed but the metadata indices won't get updated).


--sync must be specified after the --erase option.

The directory component from file is removed, then the sources and packages subdirectories in the repository directory are searched for file. This gives some flexibility in how the file is specified. A source or binary package file can be provided verbatim, or the list can be produced by a script:

find $repository/`lpm -q --distribution`/sources \
  -mtime +365 -type f -print | xargs lpm --erase $repository

Remote repositories

A remote repository is a local file directory that automatically mirrors a primary repository that's published on a web site. The --init remote option creates a directory, then downloads the primary repository's GPG keys from url, along with the initial mirror of url's package metadata.

The --authkey option sets the authorization key for a restricted access repository. If url refers to a restricted access repository, a valid authorization key must be provided with this option. See LPMtool's manual for more information on restricted access repositories. Use the --authkey option alone to change the authorization key of an existing remote repository. The new authorization key replaces the initial authorization key set when the remote repository was initially created.

The initial mirroring may take some time, try not to interrupt it. If the initial mirroring is interrupted for any reason, the repository directory should be deleted and recreated from scratch. It might also be possible to use --sync --force options to rebuild it, provided that at least the initial GPG keys were succesfully imported.

Each time lpm accesses the remote repository directory it checks if the repository's refresh interval has expired. If so, lpm downloads any updated GPG keys and package metadata updates. Even if the repository's refresh interval has expired, the refresh process is very quick if lpm thinks the remote repository is unchanged, and lpm is almost always right. On rare occasion where LPMtool is wrong, use the --sync with the --force to rebuild the metadata indices.

The --sync option also works for remote repositories. It initiates a repository refresh cycle even if the repository's refresh interval has not expired. Please respect the repository maintainer's requested refresh interval and do not explicitly run the --sync option unless it's absolutely necessary. from the remote repository. The --sync option alone is a partial compromise. lpm initiates a normal refresh cycle, but lpm will stop if it thinks that there are no changes to the repository's contents. --sync --force should be used sparingly, and only in emergencies. It forces a full refresh cycle.

If the mirrored package information database really gets corrupted, the --repair option also takes the name of a remote repository directory. Instead of repairing the system repository, the --repair option will try to repair the metadata in the remote repository's directory.

Individual mirrors of remote repositories occasionally get out of sync. It's possible that a repository refresh happens when some repository mirrors have not yet received all the updates. The first refresh cycle hits a mirror with the new updates, but the next refresh cycle hits a stale mirror. It might look like the packages have been removed, but they'll be back on the next refresh cycle, and require to be downloaded again. For this reason lpm does not automatically delete packages from the remote repository directory if the packages are missing from the primary repository.

A manual refresh cycle must be invoked in order to remove packages no longer present in the primary repository, and the --purge option must follow the --sync.

lpm also runs the --purge option, on its own, if the primary repository's contents remain unchanged for the period of time specified by the --set-full-refresh option.

Querying remote repositories

The -q option works for remote repositories to. If the -q option is followed by -r directory, the query will run against the remote repository in directory instead of the system repository. All -q sub-options may be used, except for the -p (which wouldn't make sense).

-q checks the remote repository's refresh interval, and syncs up to the primary repository, if the refresh interval has expired. Afterwards, -q runs the query against the remote repository directory.

Downloading package files

The --get and --getsrc options are convenient tools that download the package files into the directory from the remote repository. The --get option takes a package specification in any format allowed by the -q option (name, name-release, and others) and downloads all packages that match the specification. The --getsrc option takes a complete filename of the source package file, name.src.lp. Use the -q -i options to determine the name of the source package file that was used to build a particular binary package.

--get and --getsrc can process more than one package in one go. For each processed package, --get and --getsrc print the full pathname to each file after it's downloaded. If the file is already downloaded its pathname is printed immediately, without downloading it again. The package files get cached in directory, and get cleaned up automatically by the --sync --purge option.

Repository delegation

This is an advanced topic. It is possible for a primary repository, that's published on the web, to delegate a specific distribution to a different URL. As an example, consider a repository /var/www/html/repo whose equivalent URL is The repository contains two distribution subdirectories: fc2.i386 and fc2.x86_64. The repository's published URL is and all is well, since i386 clients automatically download packages from the fc2.i386 subdirectory, and x86_64 clients automatically download packages from the x86_64 subdirectory.

Now suppose that the x86_64 stuff should be moved someplace else, say, whose equivalent directory would be /var/www2/html/repo. Run the following commands after creating the new repository. The x86_64 version of lpm must be used, so that it updates only the fc2.x86_64 subdirectory in both cases:

lpm --set-url /var/www/html/repo
lpm --set-url /var/www/html2/repo

lpm --set-url repository url declares url as the URL of the repository. A repository's URL does not normally need an explicit declaration, because it is specified by --init remote (or lpm takes it from the package itself, as described in the Registered remote repositories section). When lpm picks up a different URL from the repository, it automatically resynchronizes to the new repository.


The reason both the old and the new repositories must have their URL set, is because the repository's original URL does not actually get replaced. It merely overrides the predefined URL. lpm picks up the new URL and resynchronizes. If the new repository does not have an explicitly URL, lpm goes back to the original URL and keeps flip-flopping between the URLs in this manner.

Other things to note:

  • All packages may be removed from the old URL after the delegated URL gets set.

  • Packages published in the new repository must use the new URL in their Repository: header.

  • PGP key management is slightly tricky. The old repository should install an updated keyfile. The keyfile must include the delagate repository's public keys, and signed by one of old repository's existing keys.

If url is not specified, it gets reset to the original URL, effectively removing the redirection to the new URL.

Registered remote repositories

LPMtool maintains a collection of registered remote repositories. The registered repositories are automatically searched for missing dependencies when packages are in the process of being installed. Registering a repository gives a blanket permission to download and install any package from the repository needed to fill a missing dependency. A properly-built application will include information in its packages that LPMtool can use to locate any repositories that contain any required secondary packages. If needed, LPMtool will ask for permission before adding the required repository to its list of registered remote repositories. If the permission is withheld, the package installation will probably fail because the required packages will not be available.

It important to note what adding a registered repository means. It means that LPMtool can automatically install any package from the remote repository. LPMtool will do that without any further prompting, or asking. However, all the usual security measures remain in place: all downloaded files must have a valid GPG signature, and each registered repository maintains its own GPG keyring.

The --remote --list option produces a numbered list of all registered repositories. The list shows each repository's name, and its URL. The --remote --remove option removes a registered repository. Select the repository to remove, n, by its number as shown by --remote --list.

The --remote --add option adds a new remote repository to the list of registered repositories. This process includes downloading the initial set of GPG keys, and the current contents of the repository.


It is not possible to validate that initial list of GPG keys. There's nothing to validate it against. Therefore, there exists a small window of vulnerability that may allow the repository's GPG keys to be compromised. Once, the initial GPG keys are installed, though, everything else downloaded from the remote repository must have a good signature.

Therefore an out-of-band mechanism should be used to verify the validity of the initial set of GPG keys. Better yet: don't add new registered repositories manually, at all. Instead, let LPMtool automatically add the registered repository when it tries to install an application that needs a package from a remote repository. The application's package will include the new remote repository's keys. Presumably, the application's package file itself will have a valid GPG signature. The application's signed package file will include keys of all remote repositories that provide other packages meeded by this application. Presumably, whoever built the application's package verified that the other repository's keys are valid, and are to be trusted.

In other words: package A, from repository B, requires package C which comes from repository D. Repository B already exists and package A carries a valid GPG signature by one of repository B's key. Repository D's keys will be included in package A's contents. LPMtool can now securely initialize a new registered repository D, because it already has its keys from a trusted source: package A from repository B.

Another alternative is to specify the -p option that names an existing package. The repository's URL and keys are obtained from the package database. A new package repository normally gets registered after the first package from that repository gets installed. If, for some reason, the prompt to register the repository is declined, the repository can be registered later with the -p.

The registered remote repositories will be periodically refreshed according to each repository's refresh interval setting. The --sync option has a --all option that forces a refresh of all registered repositories.


--all does not automatically delete information about packages that appear to be removed from the primary repository. Specify the --purge option after --all in order to have the deleted packages' information removed.

This is due to the issue with stale mirrors, which was described in the Remote repository section, earlier.

The --update option searches all registered repositories for any updates to existing packages, and installs them. --update is equivalent to the -u option with a list of all registered remote repositories.

--check only downloads the updated packages, and does not install them. Instead, their names are printed to standard output. Use the --update option again, without --check, to install the packages. --check should be used together with -Q, which suppresses all other irrelevant messages:

lpm --update -Q --check

If this command terminates with a zero exit code, and generates any output, its output will list all updated packages available for immediate installation.


  • It is impossible to accurately compute, down to the last byte, how much disk space is required to install a set of packages. lpm tries to make a good, educated guess. Hopefully, it'll err on the side of safety.


lpbuild(1), mklpmcompat(1).