Page Body

GNU/Linux Package Management

Table of Contents

The ability to search for, install, inspect, and remove software through built-in package management solutions is fundamental to operating a GNU/Linux system. The following will focus on the package management systems used in the Debian and Fedora GNU/Linux distributions.

Note: If you are not familiar with the GNU/Linux command line interface, review the Conventions page before proceeding.

Package Management

GNU/Linux distributions have low-level and high-level package managers.

Low-level package managers, (e.g., dpkg, RPM) manage the unpacking of individual packages, running their associated scripts, and getting the software correctly installed.

High-level package managers (e.g., APT, DNF) work with groups of packages, download packages from a vendor, and manage dependencies.

Packages

Different GNU/Linux distributions use different package formats.

.deb (Debian)

Debian binary packages are .deb packages. They have names that indicate the software contained within them and their version:

liferea_1.12.6-1_amd64.deb

The filename above contains the liferea program's 1.12.6 version. In particular, this is the first release (-1) of this package within the distribution. Packages that have been specifically developed for Debian do not include a Debian release number.

The amd64 indicates that the package contains architecture-specific parts for Intel and AMD x86 processors (and compatibles) in 64-bit mode. 32-bit packages use i386, and packages that contain only documentation or architecture-independent scripts use all, instead.

A Debian .deb binary package is an archive created using the ar command (this command is part of the binutils package and will likely need to be installed on your distribution, e.g., # apt install binutils) and generally contains three components:

  1. The debian-binary file contains the version number of the package format (currently 2.0 for the example below).
  2. control.tar.xz contains Debian-specific scripts and control files.
  3. data.tar.xz has the actual package files.
$ apt download liferea
Get:1 http://deb.debian.org/debian buster/main amd64 liferea amd64 1.12.6-1 [220 kB]
Fetched 220 kB in 0s (454 kB/s)
$ ar t liferea_1.12.6-1_amd64.deb
debian-binary
control.tar.xz
data.tar.xz

During installation, control.tar.xz is unpacked first. This makes it possible for a preinst script to be executed prior to unpacking the actual package files. After that, data.tar.xz is unpacked and the package is configured, if necessary, by executing the postinst script from control.tar.xz.

ar is used to create these packages, versus a command like tar, because ar archives only contain flat sets of files. This makes ar suitable for building sets of assembled object code in separate files, while tar is more suitable for packaging up a directory for distribution.

Source Code Archives (Debian)

In addition to a .deb binary package, each Debian package has several source code files associated with it. The .deb binary package is created from the source code files of the package. A basic principle of the Debian project is to clearly distinguish between the original source code and any Debian-specific changes.

You can obtain a Debian package's source code from the repository with the following command:

apt-get source ex_package...

Before running apt-get source, you may need to install the dpkg-dev package (# apt install dpkg-dev).

A Debian package's source code is contained in a .orig.tar.gz archive (e.g., liferea_1.12.6-1.orig.tar.gz). All changes for each package version's source code are placed in a separate .debian.tar.xz archive (e.g., liferea_1.12.6-1.debian.tar.xz). These .debian.tar.xz files include fixes and customizations to the software itself.

For each package version's source code, there is also a Debian Source Control file (using the .dsc suffix) containing checksums for the original source code archive (e.g., liferea_1.12.6-1.orig.tar.gz) and the changes archive (e.g., liferea_1.12.6-1.debian.tar.xz). The .dsc file is signed by the Debian maintainer in charge of the package.

$ apt-get source liferea
Reading package lists... Done
NOTICE: 'liferea' packaging is maintained in the 'Git' version control system at:
https://salsa.debian.org/debian/liferea.git
Please use:
git clone https://salsa.debian.org/debian/liferea.git
to retrieve the latest (possibly unreleased) updates to the package.
Need to get 1,551 kB of source archives.
Get:1 http://deb.debian.org/debian buster/main liferea 1.12.6-1 (dsc) [1,919 B]
Get:2 http://deb.debian.org/debian buster/main liferea 1.12.6-1 (tar) [1,527 kB]
Get:3 http://deb.debian.org/debian buster/main liferea 1.12.6-1 (diff) [22.0 kB]
Fetched 1,551 kB in 1s (1,388 kB/s)
dpkg-source: info: extracting liferea in liferea-1.12.6
dpkg-source: info: unpacking liferea_1.12.6.orig.tar.gz
dpkg-source: info: unpacking liferea_1.12.6-1.debian.tar.xz
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: applying debian-example-feeds.patch
dpkg-source: info: applying www-browser.patch
dpkg-source: info: applying fix-FTBFS-on-missing-file-POTFILES.IN.patch
$ ls -l liferea_*
-rw-r--r-- 1 amnesia amnesia   21960 Dec  9  2018 liferea_1.12.6-1.debian.tar.xz
-rw-r--r-- 1 amnesia amnesia    1919 Dec  9  2018 liferea_1.12.6-1.dsc
-rw-r--r-- 1 amnesia amnesia 1526678 Dec  9  2018 liferea_1.12.6.orig.tar.gz

From above, you can see that the original source code archive does not change for all of the 1.12.6 releases of the program (i.e., it does not contain a Debian release number). Every new release of the Debian package of liferea's 1.12.6 version comes with new .debian.tar.xz and .dsc files. Each new .debian.tar.xz file contains all of the changes relative to the original archive (i.e., liferea_1.12.6.orig.tar.gz).

To summarize, a given Debian package will have the additional source code files associated with it:

  1. An original source code archive (ex_program_version.number.orig.tar.gz).
  2. A Debian-specific changes archive (ex_program_version.number-release_number.debian.tar.xz).
  3. A source control file (ex_program_version.number-release_number.dsc), which provides checksums for the above two archives and is signed by the Debian package's maintainer.

Previously, the Debian project used a less complicated structure where there was a single file (created with diff) containing all Debian-specific changes (in the above example, hypothetically liferea_1.12.6-1.diff.gz). This approach is still supported, and you may find this structure with older packages. The new structure does have the advantage that different changes can be more cleanly separated, which simplifies maintaining the package within the Debian project.

.rpm (Fedora)

Fedora binary packages are RPM Package Manager (RPM) packages (.rpm). RPM packages are compiled for a specific architecture and, sometimes, a specific GNU/Linux distribution.

RPM packages have compound filenames (e.g., liferea-1.12.7-3.fc31.x86_64.rpm). The package names contain the following information:

  • Package name (e.g., liferea)
  • Version number (e.g., 1.12.7)
  • Release number (e.g., 3)
  • Compatible distribution (e.g., fc31; this is optional)
  • Architecture type (e.g., x86_64)

Usually, the name consists of the package name, the architecture, and the .rpm suffix. The package name is used to internally identify the package once it has been installed. It contains the name of the software and the software version as assigned by its original developers, followed by a release number assigned by the package builder (i.e., the distributor).

Essentially, RPM packages are cpio archives with a prepended header. This fact can be used to extract individual files from an RPM package without having to install the package first. To do so, you can convert a RPM package into a cpio archive using the rpm2cpio program, and feed the archive into cpio.

$ dnf download liferea
Fedora Modular 31 - x86_64                      719 kB/s | 5.2 MB     00:07    
Fedora Modular 31 - x86_64 - Updates            206 kB/s | 4.2 MB     00:21    
Fedora 31 - x86_64 - Updates                    354 kB/s |  27 MB     01:18    
Fedora 31 - x86_64                              513 kB/s |  71 MB     02:21    
Last metadata expiration check: 0:00:01 ago on Wed 09 Sep 2020 06:16:35 PM PDT.
liferea-1.12.7-3.fc31.x86_64.rpm                926 kB/s | 943 kB     00:01
$ rpm2cpio liferea-1.12.7-3.fc31.x86_64.rpm | cpio -div ./usr/share/man/man1/liferea.1.gz
./usr/share/man/man1/liferea.1.gz
6561 blocks
$ zcat usr/share/man/man1/liferea.1.gz | head
.TH LIFEREA "1" "Dec 26, 2015"
.SH NAME
Liferea \- GTK desktop news aggregator

.SH SYNOPSIS
.B liferea
.RI [\fIOPTIONS\fR]

.SH DESCRIPTION
\fBLiferea\fP (Linux Feed Reader) is an aggregator for online

Low-Level Package Management

dpkg (Debian)

Low-level package management on Debian is handled by Debian Package (dpkg).

/var/lib/dpkg/
dpkg database directory.
/etc/dpkg/dpkg.cfg
dpkg configuration file.

Options for dpkg can be given on the command line or else placed in /etc/dpkg/dpkg.cfg. For options placed in the /etc/dpkg/dpkg.cfg file, dashes (-) at the start of option names must be omitted.

Debian Package Priorities

These are the Debian package priorities, from highest to lowest:

required
Packages that are necessary for proper operation of the system (usually because dpkg depends on them).
important
Encompasses packages one would expect to be available on a GNU/Linux system.
standard
Adds those packages that make sense for a networked system (but not an overly restrictive system) running in text mode. This priority describes what you get if you install Debian without selecting any additional packages.
optional
This is the default priority for the majority of the archive. Applies to everything you might want to install if you have no particular requirements (e.g., the X11 Graphical User Interface, or GUI). Packages with a priority of optional may conflict with each other.
extra
This priority is deprecated. Use the optional priority instead. This priority should be treated as equivalent to optional.

Packages may not depend on packages of lower priority. For this to hold in all cases, the priorities of some packages have been deliberately adjusted.

Debian Package Dependencies

Debian package dependencies include:

Depends
This declares an absolute dependency. The named packages must be configured for the package in question to be configured. Specific versions of the packages may be called for.
Recommends
This declares a strong, but not absolute, dependency (i.e., a non-absolute, but obvious dependency). Named packages should nearly always be installed along with this package, unless there are unusual circumstances.
Suggests
This is used to declare that one package may be more useful with one or more other packages (i.e., the named packages are useful in connection with the package, but not required).
Enhances
Like Suggests, but in reverse. It is used to declare that a package can enhance the functionality of another package.
Pre-Depends
Like Depends, except the named packages must be completely installed before installation of the package in question can begin. For example, this type of dependency is used if the package's installation scripts absolutely require software from the other package(s).
Breaks
When one binary package declares that it breaks another, dpkg will refuse to allow the package which declares Breaks to be unpacked unless the broken package is deconfigured first, and it will refuse to allow the broken package to be reconfigured.
In short, this package cannot be installed until the named package(s) is uninstalled.
Conflicts
When one binary package declares a conflict with another using a Conflicts field, dpkg will refuse to allow them to be unpacked on the system at the same time. This is a stronger restriction than Breaks, which prevents the broken package from being configured while the breaking package is in the Unpacked state, but allows both packages to be unpacked at the same time.
In short, this package cannot be installed at the same time as the named package(s).
Debian Package Integrity

The Debian project ensures the integrity of complete packages (and, based on this, the integrity of the whole distribution) as follows:

  • Every Debian package is cryptographically signed by a Debian developer. This means that the recipient of the package can use the developer's public key to verify that they received the package in the state it was in when the developer released it.
  • The Debian infrastructure only accepts packages for publication that have been signed by a Debian developer.
  • On the Debian server (and all servers mirroring Debian), there is a file (or several files) called Packages.xz for each current Debian distribution. This file contains the SHA256 checksum of all packages in the distribution, as they are on the server. Since the server only accepts packages from approved developers, these are authentic.
  • For each current Debian distribution on the server there is also a file called Release, which contains the SHA256 checksums of the Packages.xz file(s) involved for that given Debian distribution. This file is cryptographically signed (the signature is in a file called Release.gpg).

Keep in mind, a developer's signature does not guarantee that there is no malicious code in a package, but only that the developer signed the package. Most other GNU/Linux distributions share this weakness.

With Debian's chain of checksums and signatures, the integrity of packages in the distribution can be checked:

  • With the checksum from the Release file, we can verify the integrity of the actual Packages.xz file.
  • The SHA256 checksum of the package given in Packages.xz must match that of the downloaded file.

If the SHA256 checksum of the downloaded file does not match the nominal value from Packages.xz, the system administrator is made aware of this fact and the package is not installed.

dpkg Commands
dpkg -l, dpkg --list
List all packages in the dpkg database. The -l option can be passed the name of a package to only see a listing for that package.
Shell search patterns are supported.
The first three columns of output show the desired action, package status, and errors.

Desired Action:

  • u Unknown
  • i Install
  • h Hold
  • r Remove
  • p Purge

Package Status:

  • n Not-installed
  • c Config-files
  • H Half-installed
  • U Unpacked
  • F Half-configured
  • W Triggers-awaiting
  • t Triggers-pending
  • i Installed

Error Flags

  • <empty> (none)
  • R Reinst-required

Packages with version <none> are part of the distribution, but are either not installed on the current system (i.e., status un), or have been removed (i.e., status pn).

dpkg --get-selections > ex_file.txt
List all package selections and save to a file.
# dpkg --set-selections < ex_file.txt
Set package selections using a file read from the standard input. This can be used to install dpkg packages from a file.
ex_file.txt contains a list of package names, one package per line. You can make such a file with the dpkg --get-selections > ex_file.txt command.
dpkg -L ex_package..., dpkg --listfiles ex_package...
List the files in a dpkg package.
dpkg -S ex_filename_string..., dpkg --search ex_filename_string...
Search the dpkg database for a filename string.
This command's output gives you the file path for the file, as well as the package that it is associated with. It can be used to see which package (if any) is associated with a given file.
Shell search patterns are supported.
If you are looking for the package for a file that is not on your system, you can use the search form on https://www.debian.org/distrib/packages#search_contents. This allows you to search all Debian distributions and architectures, as well as to search for exact filename matches and filenames containing certain search terms.
dpkg --info ex_package.deb
Display information about a .deb package, including its dependencies.
dpkg -s ex_package..., dpkg --status ex_package...
Display information about a dpkg package, including its dependencies.
Aside from the package name, this command's output includes information about the package's status and priority, and its approximate area of interest (i.e., Section:). The Maintainer: is the person that is in charge of the package on behalf of the Debian project.
# dpkg -i ex_package.deb..., # dpkg --install ex_package.deb...
Install a .deb package. After running this command, run # apt-get install -f to resolve any broken dependencies (-f is short for --fix-broken).
A dpkg package can be reinstalled from a .deb package with the # apt-get reinstall ex_package.deb command.
# dpkg --unpack ex_package.deb...
Unpack a .deb package.
# dpkg --configure ex_package.deb...
Configure a .deb package.
dpkg --force-help
Display dpkg forcing options.
# dpkg -i --force-depends ex_package.deb..., # dpkg --install --force-depends ex_package.deb...
Force install a .deb package with dependency errors. Turns all dependency problems into warnings.
This can be used when a package requires one or more other packages that either have not yet been installed, or that are not included in the same installation operation.
Sometimes, packages do not depend on a particular other package, but on a virtual package that can be provided by any of several other packages. A list of virtual package names can be found at https://www.debian.org/doc/packaging-manuals/virtual-package-names-list.yaml (direct download link).
# dpkg -i --force-overwrite ex_package.deb..., # dpkg --install --force-overwrite ex_package.deb...
Force install a .deb package that tries to unpack a file that already exists on the system and belongs to a different package (i.e., overwrite a file from one package with another).
# dpkg -i --force-conflicts ex_package.deb..., # dpkg --install --force-conflicts ex_package.deb...
Force install a .deb package that conflicts with other packages.
# dpkg -r ex_package..., # dpkg --remove ex_package...
Remove a dpkg package.
The package's configuration files (i.e., all the files listed in the conffiles file within control.tar.gz) are kept in order to facilitate a subsequent re-installation of the package.
# dpkg -r --force-remove-reinstreq ex_package..., # dpkg --remove --force-remove-reinstreq ex_package...
Force removal of a dpkg package that requires re-installation.
# dpkg -r --force-remove-essential ex_package..., # dpkg --remove --force-remove-essential ex_package...
Force removal of a dpkg package that that is essential for other packages.
# dpkg -P ex_package..., # dpkg --purge ex_package...
Remove a dpkg package, along with its configuration files.
# dpkg -i ex_package.deb..., # dpkg --install ex_package.deb...
Upgrade a dpkg package from a .deb package.
The older version of ex_package is uninstalled before configuration of the new version. If an error occurs during installation, the old version can often be restored.
If an earlier version of the package is installed and set to hold (e.g., using a tool like aptitude), newer versions of the package will be prevented from being installed.
dpkg-source -x ex_package.dsc, dpkg-source --extract ex_package.dsc
Reconstruct a .deb package's source code. The package's source control file is provided to the -x option as an argument. The .deb package's original source archive (ex_package.orig.tar.gz) and Debian-specific changes archive (ex_package.debian.tar.xz) must be in the same directory as the source control file.
If a directory location is not provided to the command as a second argument (if provided, this directory must not yet exist, as dpkg-source will create it), the source package is extracted into a directory named source-version under the current working directory.
dpkg-source is also used when generating source archives and Debian change files during Debian package preparation. This command is installed as part of the dpkg-dev package, which may need to manually installed from Debian's repository on your system (# apt install dpkg-dev).
# dpkg-reconfigure ex_package...
Reconfigure an already installed dpkg package.
alien --to-deb ex_package...
Convert a non-.deb package to a .deb package. --to-deb is the default option and can be left out if that is the desired outcome.
alien does not deal with dependencies, so those must be manually addressed (i.e., run # apt-get install -f). To assemble and disassemble .rpm files, the rpm program must be installed (which is available as a package for Debian in its repository (# apt install rpm).
There is no guarantee that the resulting package created by this command will be viable. The farther down a package sits in the system, the smaller the probability that alien will create a working package for your GNU/Linux distribution.
debsums ex_package...
Verify a dpkg package.
This command compares the SHA256 checksums of the individual files with the content of the corresponding file in /var/lib/dpkg/info (e.g., liferea.sha256sums). If an actual file's checksum does not match the set value, FAILED is displayed in place of OK.

RPM (Fedora)

Low-level package management on Fedora is handled by RPM, which uses the rpm command, followed by a basic mode. There are a number of global options, as well as supplementary, mode-specific options.

Since some modes and supplementary options are identical, the mode must be specified first. Global options include -v and -vv, which increases the verbosity of RPM's output.

/var/lib/rpm/
RPM database directory.
/usr/lib/rpm/
RPM configuration directory.
RPM Commands
rpm -q -a, rpm --query --all
List all packages in the RPM database. By default, this only lists the full package names.
rpm -q ex_package_name..., rpm --query ex_package_name...
List RPM database entry for a specific package. If provided an abbreviated internal package name, the full package name will be output, if it is installed.
rpm -q -l -p ex_package.rpm, rpm --query --list --package ex_package.rpm
List the files in a .rpm package.
rpm -q -l ex_package..., rpm --query --list ex_package...
List the files in a RPM package.
The files listed are only those that appear in the RPM database, i.e., those that a package brought with it when it was installed. This does not include files that were generated during installation or during system operation.
The -c (--configfiles) and -d (--docfiles) options behave like -l, except that they can be used to view only configuration and documentation files, respectively.
rpm -q -f ex_file..., rpm --query --file ex_file...
Determine which RPM package a file belongs to.
This command lets you relate unknown files to a package.
rpm -q -a | grep 'ex_package_name_string', rpm --query --all | grep 'ex_package_name_string'
Search the RPM database for a package name string.
rpm -q -i -p ex_package.rpm, rpm --query --info --package ex_package.rpm
Display information about a .rpm package. The output does not include dependency information. When used with -q, -i is short for --info.
rpm -q -i ex_package..., rpm --query --info ex_package...
Display information about a RPM package. The output does not include dependency information.
rpm -q -R -p ex_package.rpm, rpm --query --requires --package ex_package.rpm
List capabilities on which this .rpm package depends.
This command displays the files and capabilities (e.g., web_browser) that a package requires. Letting packages depend on capabilities, instead of specific dependencies, gives RPM flexibility.
rpm -q -R ex_package..., rpm --query --requires ex_package...
List capabilities on which a RPM package depends.
rpm -q --provides ex_package..., rpm --query --provides ex_package...
Display capabilities that a RPM package offers.
rpm -q --whatprovides ex_capability, rpm --query --whatprovides ex_capability
Display RPM package(s) providing a specific capability.
rpm -q --whatrequires ex_capability, rpm --query --whatrequires ex_capability
Display RPM packages that require a specific capability for proper functioning.
rpm -q --changelog ex_package..., rpm --query --changelog ex_package...
Show changelog for a RPM package.
# rpm -i ex_package.rpm..., # rpm --install ex_package.rpm...
Install a .rpm package.
rpm automatically checks to see if dependent software is installed before installing a new package.
Shell search patterns are supported.
The --test and -h (--hash) options can be added to # rpm -i ex_package.rpm... to check for conflicts before installation and to add a progress bar, respectively.
Instead of providing a .rpm package as an argument, an HTTP or FTP URL can be substituted in order to install package files from a remote server.
# rpm -i --nodeps ex_package.rpm..., # rpm --install --nodeps ex_package.rpm...
Do not do a dependency check before installing or upgrading a package (i.e., force install a .rpm package with dependency errors).
You can also use other options to influence the installation itself (rather than just the security checks), e.g., to specify a different installation directory for a program, so you can have two different versions of it installed at the same time.
# rpm -i --replacefiles ex_package.rpm..., # rpm --install --replacefiles ex_package.rpm...
Install the package(s) even if it replaces files from other, already installed, packages (i.e., force install a .rpm package that will overwrite files).
# rpm -i --force ex_package.rpm..., # rpm --install --force ex_package.rpm...
Same as using the --replacepkgs, --replacefiles, and --oldpackage options (i.e., force install a .rpm package that requires safety overrides, including overwriting files).
Conflicts arise if:
  • An already-installed package is to be installed again.
  • A package is to be installed, even though it is already installed in a different version (mode -i) or a more current version (mode -U).
  • The installation would overwrite a file belonging to a different package.
  • A package requires a different package that is not already installed or about to be installed.
# rpm --reinstall -f ex_package.rpm..., # rpm --reinstall --file ex_package.rpm...
Reinstall a RPM package from a .rpm package file. An alternative is # rpm -U --replacepkgs ex_package.rpm..., where -U is short for --upgrade.
# rpm -e ex_package..., # rpm --erase ex_package...
Remove a RPM package. The provided package name can be abbreviated, as long as it stays unique (e.g., liferea-1.12.7-3.fc31.x86_64.rpm versus liferea).
The --test and --nodeps options can be added to check for conflicts and disable dependency checks (i.e., the package will be removed even if other packages are depending on it), respectively. The --allmatches option can be added to remove all versions of a RPM package.
When removing a RPM package, all of the package's installed files will be removed, unless they are configuration files that you have changed. The changed files will not be removed, but renamed by appending the .rpmsave suffix (the RPM package determines which of its files will be considered configuration files).
# rpm -U ex_package.rpm..., # rpm --upgrade ex_package.rpm...
Upgrade a RPM package from a .rpm package.
This command removes any older versions of ex_package.rpm and installs the new one. If ex_package.rpm is not already installed, it will be installed.
# rpm -F ex_package.rpm..., # rpm --freshen ex_package.rpm...
Freshen a RPM package from a .rpm package.
This command installs ex_package.rpm only if an earlier version is already installed (which is subsequently removed), i.e., it is like a stricter version of # rpm -U ex_package.rpm....
alien --to-rpm ex_package.deb...
Convert a .deb package to a .rpm package.
To assemble a .deb package, the gcc, make, debhelper, dpkg-dev, and dpkg packages must be installed (# dnf install gcc make debhelper dpkg-dev dpkg).
There is no guarantee that the resulting package created by this command will be viable. The farther down a package sits in the system, the smaller the probability that alien will create a working package for your GNU/Linux distribution.
# rpm --rebuilddb
Rebuild the RPM Database.
rpmkeys -K ex_package.rpm..., rpmkeys --checksig ex_package.rpm...
Verify a .rpm package.
This command compares a checksum of the package to the checksum contained in the ex_package.rpm itself. This guarantees the proper transmission of the package.
The signature within ex_package.rpm, which was created using the private PGP or GPG key of the package preparer, is checked using the package preparer's public key, which must be available on your GNU/Linux system. This guarantees that the correct package has arrived.
rpm -V ex_package..., rpm --verify ex_package...
Verify a RPM package.
This command's output will contain all files for which at least one required value from the database differs from the actual value within the file system. A . signifies agreement, while a letter indicates a deviation.
The following checks are performed:
  • Access mode and file type (M)
  • User owner and group owner (U,G)
  • For symbolic links, the path of the referenced file (L)
  • For device files, major and minor device numbers (D)
  • For plain files, the size (S)
  • Modification time (T)
  • Content (5), i.e., the digest (formerly MD5 sum) differs

Configuration files are unlikely to remain in their original state, so they are labeled with a c.

Add the -a (--all) and -c (--configfiles) options to verify all RPM packages or package(s) configuration files, respectively.

$ rpm -V openssh
.......T c /etc/init.d/sshd
S.5....T c /etc/pam.d/sshd
S.5....T c /etc/ssh/ssh_config
SM5....T c /etc/ssh/sshd_config
.M...... /usr/bin/ssh
rpm -q gpg-pubkey --queryformat '%{NAME}-%{VERSION}-%{RELEASE}\t%{SUMMARY}\n', rpm --query gpg-pubkey --queryformat '%{NAME}-%{VERSION}-%{RELEASE}\t%{SUMMARY}\n'
View trusted keys.
rpm -q -i ex_gpg-pubkey..., rpm --query --info ex_gpg-pubkey...
Inspect a specific key (e.g., rpm -q -i gpg-pubkey-3c3359c4-5c6ae44d).
# rpm -e ex_gpg-pubkey..., # rpm --erase ex_gpg-pubkey...
Remove a specific key (e.g., # rpm -e gpg-pubkey-3c3359c4-5c6ae44d).

High-Level Package Management

APT (Debian)

High-level package management on Debian is handled by the Advanced Package Tool (APT).

/var/lib/apt/
APT database directory (contrast this to the /var/lib/dpkg database directory for dpkg).
/etc/apt/apt.conf.d/
APT configuration directory (contrast this to the /etc/dpkg/dpkg.cfg configuration file for dpkg).
/etc/apt/sources.list
APT repository sources file.
/etc/apt/sources.list.d/
APT repository sources directory.

Binary packages are fetched from http://ftp.de.debian.org/, as is the corresponding source code.

Numerous auxiliary tools allow for setting up caching proxy servers for Debian packages, installing packages on systems that are not connected to the Internet, or retrieving a list of bugs for a package before actually installing it (e.g., apt-listbugs). With apt-build, you can compile packages with specific optimizations for your GNU/Linux system and create a local package repository containing such packages.

APT's installation history can be viewed by running less /var/log/apt/history.log.

The APT infrastructure only trusts package sources for which a public GPG key has been placed in the /etc/apt/trusted.gpg.d/ directory. The apt-key program is used to maintain the files in this directory. The current public keys for Debian package sources are contained in the debian-archive-keyring package and can be renewed by updating the files in /etc/apt/trusted.gpg.d/ (Debian rotates the keys on a yearly basis).

APT Commands
apt-cache policy
List the priorities of configured APT repositories. If provided a package as an argument, prints out detailed information about the priority selection of the provided package.
apt list ex_package...
List an APT package. Shell search patterns are supported.
Contrast this to dpkg -l (--list) for dpkg.
apt search ex_reg_ex
Search APT repositories for a given regular expression.
Contrast this to dpkg -S ex_string... (--search) for dpkg.
apt show ex_package...
Display APT package information, including its dependencies, installation and download size, sources the package is available from, the description of the package's content, and more.
Contrast this to dpkg --info ex_package.deb and dpkg -s ex_package... (--status) for dpkg.
apt depends ex_package...
Display all dependencies of an APT package.
This command shows all the dependencies of an APT package, as well as the names of packages fulfilling that dependency. A vertical bar in a line indicates that the dependency in that line, or the one in the following line, must be fulfilled.
Contrast this to dpkg --info ex_package.deb and dpkg -s ex_package... (--status) for dpkg.
apt rdepends ex_package...
Display all packages depending on an APT package.
If a package occurs several times in the output, it is probably because the original package specified it several times, typically with version numbers.
apt-cache stats
Display an overview of the contents of the package cache.
# apt install ex_package...
Install an APT package.
This command will also install or upgrade all packages mentioned in Depends: dependencies, as well as any packages that these packages depend upon.
apt install can be used to simultaneously install and remove packages (e.g., # apt install liferea- python python-django+ removes liferea and installs python and python-django; the + is optional).
Contrast to # dpkg -i ex_package.deb... (--install) for dpkg.
# apt-get install -f, # apt-get install --fix-broken
Attempt to correct a system with broken dependencies in place.
apt-mark showmanual > ex_file.txt
List manually installed APT packages and save to a file.
Contrast this to dpkg --get-selections > ex_file.txt for dpkg.
# apt install "$(cat ex_file.txt)"
Install APT packages listed in a file.
Contrast this to # dpkg --set-selections < ex_file.txt for dpkg.
# apt-get reinstall ex_package...
Reinstall an APT package.
apt download ex_package
Download an APT package's .deb file to the current directory.
apt-get source ex_package
Download an APT package's source code to the current directory.
This command also works if ex_package is one of several that have been created from a differently named source package.
# apt remove ex_package...
Remove an APT package.
Contrast to # dpkg -r ex_package... (--remove) for dpkg.
# apt purge ex_package...
Remove an APT package and its configuration files.
Contrast to # dpkg -P ex_package... (--purge) for dpkg.
# apt-get autoclean
Clears out the local repository of retrieved package files. Only removes package files that can no longer be downloaded, and are largely useless.
# apt-get autoremove
Remove packages that were automatically installed to satisfy dependencies for other packages and are no longer needed.
# apt update
Update APT repositories (i.e., download package information from all configured sources).
This command updates the local package availability database. It consults all package sources and integrates the results into a common package list.
apt list --upgradeable
List APT packages with available upgrades.
# apt upgrade
Conservatively upgrade APT packages. A single APT package can be upgraded by providing its name to this command as an argument.
This command installs the newest available versions of all packages installed on the system. It will not remove installed packages, nor install new packages. Packages that cannot be updated without such action (because dependencies have changed) remain at their present state.
Contrast to # dpkg -i ex_package.deb (--install) for dpkg.
# apt full-upgrade
Liberally upgrade APT packages, with removals.
This command enables a conflict resolution scheme that tries to resolve changed dependencies by judiciously removing and installing packages. It prefers more important packages (according to their priority) over less important ones.
apt-key list
List trusted keys with fingerprints. Can be used to obtain key_id values.
This command lists the keys associated with the GNU/Linux system's packaging system, APT, which are used to authenticate packages. It lists the key values in the /etc/apt/trusted.gpg.d/ directory's files.
# apt-key del ex_key_id
Remove a key.

DNF (Fedora)

High-level package management on Fedora is handled by Dandified YUM (dnf).

/var/lib/dnf/
DNF database directory (contrast this to the /var/lib/rpm/ database directory for rpm).
/etc/dnf/dnf.conf
DNF configuration file (contrast this to the /usr/lib/rpm/ configuration directory for rpm).
/etc/dnf/dnf.conf may contain software repository URLs and their names, the directory where downloaded packages will be saved, and where the DNF log file will be saved.
/etc/yum.repos.d/
DNF repository sources directory.
This directory contains repository information for dnf. Each repository has its own file in the format of ex_repo.repo. Each file may contain multiple repositories, which are grouped according to function.
For example, the main distribution repository is in one file along with the repository for the source packages and a repository for the debugging symbols. Another file contains the repositories for the updates, source for the updates, and the debugging symbols for the updates.
A repository either has a baseurl, which is a link to the repository, or it has a metalink, which returns a list of mirrors for the repository.
DNF Commands
dnf repolist
List enabled DNF repositories.
This command can be used to find repo IDs. Only enabled repositories are searched with the dnf command.
dnf repolist disabled
List disabled repositories.
# dnf --enablerepo=ex_repo_id repolist
Enable a DNF repository. ex_repo will be enabled until a system reboot.
--enablerepo can accept a comma-separated list of repositories (e.g., --enablerepo=ex_repo_id_1,ex_repo_id_2,ex_repo_id_3).
# dnf --disablerepo=ex_repo_id repolist
Disable a DNF repository. ex_repo will be disabled until a system reboot.
--disablerepo can accept a comma-separated list of repositories (e.g., --disablerepo=ex_repo_id_1,ex_repo_id_2,ex_repo_id_3).
# dnf config-manager --set-enabled ex_repo_id
Permanently enable a DNF repository.
--set-enabled can accept a space-separated list of repositories (e.g., --set-enabled ex_repo_id_1 ex_repo_id_2 ex_repo_id_3).
# dnf config-manager --set-disabled ex_repo_id
Permanently disable a DNF repository.
--set-disabled can accept a space-separated list of repositories (e.g., --set-disabled ex_repo_id_1 ex_repo_id_2 ex_repo_id_3).
dnf list ex_package...
List DNF package in RPM database, in a repository, or both.
This command just gives a line for the package, including its full name. Installed packages are installed on the local system. Available packages can be fetched from repositories. The repository offering the package is displayed on the far right.
Shell search patterns are accepted.
Contrast to rpm -q ex_package... (--query) for rpm.
dnf list installed
List locally installed DNF packages.
This command only shows packages installed in the RPM database.
Contrast to rpm -q -a (--query --all) for rpm.
dnf list updates
List installed DNF packages that have updates available.
This command is comparable to dnf check-update.
dnf list extras
List locally installed DNF packages that are not available from any repository.
dnf list available
List locally uninstalled (but available, i.e., from a repository) DNF packages.
dnf list recent
List DNF packages that have recently arrived in the repository.
dnf search ex_string
Search repositories for a given string. This command lists all packages whose name or description (i.e., its metadata) contains a given string.
Shell search patterns are supported.
Contrast this to rpm -q -a | grep 'ex_string' (--query --all) for rpm.
dnf info ex_package...
Display DNF package information. This command displays a description and summary information about installed and available packages.
Contrast this to rpm -q -i -p ex_package.rpm (--query --info --package) and rpm -q -i ex_package... (--query --info) for rpm.
dnf info installed
Display information for all installed DNF packages.
dnf deplist ex_package...
Display a DNF package's dependencies. This command produces a list of all direct dependencies and what packages provide those dependencies for the given package(s).
Contrast this to rpm -q -R -p ex_package.rpm (--query --requires --package) and rpm -q -R ex_package... (--query --requires) for rpm.
# dnf install ex_package...
Install a DNF package.
dnf checks whether the active repositories contain an appropriately-named package, resolves any dependencies the package may have, downloads the package and possibly other packages that it depends on, and installs all of them.
dnf accepts not just simple package names, but also package names with architecture specifications, version numbers, and release numbers. See man 8 dnf for the allowable formats.
Contrast this to # rpm -i ex_package.rpm... (--install) for rpm.
# dnf reinstall ex_package...
Reinstall a DNF package.
Contrast to # rpm --reinstall -f ex_package.rpm (--force) for rpm.
# dnf install --downloadonly ex_package...
Download a DNF package to the cache.
dnf download ex_package...
Download a DNF package's .rpm file to the current directory.
# dnf remove ex_package...
Remove a DNF package.
This command will also remove packages that ex_package depends on, as long as these are not required by another installed package.
Contrast to # rpm -e ex_package... (--erase) for rpm.
# dnf autoremove
Remove all leaf packages from the system that were originally installed as dependencies of user-installed packages, but which are no longer required by any such package.
# dnf clean all
Perform cleanup of temporary files for the currently enabled repositories.
dnf check-update
Update DNF repositories (i.e., checks whether any updates at all are available for your system).
This command will also list the packages that have updates available, i.e., it is equivalent to dnf list updates.
# dnf upgrade
Upgrade DNF packages. A single DNF package can be upgraded by providing its name to this command as an argument. dnf takes care that all dependencies are resolved.
The --obsoletes option ensures that dnf tries to handle the case where one package has been replaced by another of a different name. This makes full upgrades of the whole dsitribution easier to perform. This option is implied by default.
Contrast to # rpm -U ex_package.rpm... (--upgrade) for rpm.
# dnf upgrade --refresh
Update DNF repositories and upgrade DNF packages.
--refresh sets repository metadata as expired before running the upgrade mode, which causes it to refresh the repository metadata before upgrading packages.
# dnf history | head
List recent DNF transactions. Can be used to obtain transaction ID numbers.
# dnf history undo last
Undo last DNF transaction (i.e., perform the opposite operation to all operations performed in the specified transaction).
# dnf history rollback ex_transaction_id
Undo all transactions performed after the specified transaction. ex_transaction_id is the transaction ID number before the problematic transaction.
ex_transaction_id's can be obtained from the # dnf history command.
dnf grouplist
Display package groups.
Package Groups are packages that, together, are useful for a certain task. A group is considered installed if all of its mandatory packages are installed. Also, there are default packages and optional packages.
dnf groupinfo ex_package_group...
Show which packages a package group consists of.
# dnf groupinstall ex_package_group...
Install the packages of a group.
The configuration option group_package_types determines which class package will be installed, i.e., it tells dnf which type of packages in groups will be installed when groupinstall is called. The default is: default, mandatory. See man 5 dnf.conf for more information.
# dnf groupremove ex_package_group...
Remove the packages of a group.
This command does not take into account package classes (i.e., group_package_types is ignored). Keep in mind, packages can belong to more than one group at a time, so they may be missing from group A after having been removed along with group B.

Documentation

You can find more information on the commands discussed above by examining the Linux User's Manual, either at the command line or online.

Also, you can find more information on GNU/Linux package managers via their official project sites:

Enjoyed this post?

Subscribe to the feed for the latest updates.