lpm — LPMtool is a Package Management tool
lpm [-i] | [-u] | [-a] [[-f] | [--force]] [[-t] | [--test]] [-v] [-Q] file...
lpm [-e] [[-f] | [--force]] [[-t] | [--test]] [-v] [-Q] package...
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...
lpm --check [-v] [-Q] file...
lpm --verify package...
lpm --repair | --clearlock [-v] [-Q]
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]
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]
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.
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.lpi386
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:
name
Uninstall any installed version and errata releases of application
name.
name-versionUninstall any errata release of the given application version.
name-version-releaseUninstall 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.
-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.
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:
SThe file's size has changed.
MThe file's permission mode settings have changed.
5The file's MD5 checksum (the file's contents) have changed.
DThe file's type has changed (socket, FIFO, block or character device).
UThe file's user ownership has changed.
GThe file's group ownership has changed.
TThe 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.
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.
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.
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.
Once lpm -q -a completes successfully, run lpm --repair.
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:
nm
Set the refresh interval to n minutes.
nh
Set the refresh interval to n hours.
nd
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.
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.
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
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.
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.
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.
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 “http://www.example.com/repo”.
The repository contains two distribution subdirectories:
“fc2.i386” and “fc2.x86_64”.
The repository's published URL is “http://www.example.com/repo”
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 “http://x86-64.example.com/repo”, 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 http://x86-64.example.com/repo lpm --set-url /var/www/html2/repo http://x86-64.example.com/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.
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.