Introduction to Package Management Systems
There was a time when software was distributed via FTP or mailing lists (i.e., patch packages with source code distributed via mailing lists) (eventually these distribution methods evolved, thanks to the rapid growth of the Internet, into one of the common software distribution sites of today). (There is only one very small file (usually in a tar file) that contains instructions for creating the binary. All you need to do is unpack the package, read the README file carefully, and then create the binary via . /configure, make, make install to install the software. Imagine how boring and time-consuming it would be to perform the above process for every piece of software on your system, not to mention how complicated and labor-intensive it would be to update an already installed piece of software.
The concept of package is used to address the complexity of the software installation and upgrade process. A package combines multiple data files needed for software installation and upgrade into a single file, which facilitates transfer and (by compressing the file) reduces storage space, and the binary executable in the package is pre-compiled according to the compilation identifier chosen by the developer. The package itself contains all the required metadata, such as the name of the software, the description of the software, the version number, and the dependent packages needed to run the software, etc.
Different schools of Linux distributions have created their own package formats, the most common of which are
- .deb: This package format is used by Debian, Ubuntu, Linux Mint, and other variants. This was the first package type to be invented.
- rpm: This package format was originally called the Red Hat Package Manager (LCTT). Linux distributions that use this package include Red Hat, Fedora, SUSE, and some other smaller distributions.
- .tar.xz: This package format is simply a software archive, which is the format used by Arch Linux. (LCTT note: this format does not require a special package manager, just unzip it)
Although the above package formats do not directly manage software dependencies on their own, they are a big step forward in Linux package management.
Years ago, the concept of a repository was difficult to understand for non-users of the Linux world. Even today, most users working entirely under Windows are used to opening a browser, searching for software (or upgrade packages) to install, downloading them, and installing them. However, smartphones have spread the concept of an AppStore (software store/application) marketplace. The way smartphone users get software is already very similar to the way package managers work. The difference is that most Linux users prefer to use the command line to install software, even though most software stores are still trying to beautify their graphical interfaces to attract users. In a nutshell, a repository is a centralized list of installable software, listing all the software that can be installed in a pre-configured repository on the current system.
In Linux distributions, almost every distribution has its own package manager. The common ones are.
- Debian’s dpkg and its
- front-end apt (used in Debian, Ubuntu).
- Red Hat’s RPM package manager and its
- front-end dnf (used in Fedora, CentOS 8)
- Front-end yum (used on Red Hat Enterprise Linux, CentOS 7 and below)
- Front-end ZYpp (used in openSUSE)
- Front-end urpmi (used on Mandriva Linux, Mageia)
- Other package managers are
- Pacman used in ArchLinux
- Source-based Portage for Gentoo
- Homebrew for Mac systems, etc.
Using a package manager will greatly simplify the process of installing software in a Linux distribution.
Why do you need a package manager with its front-end tools?
Package managers such as RPM and DPKG can only check for dependencies and tell the user that the dependencies are not met when installing or removing, and then the user has to find out the required components to install on their own. This is very inconvenient, in order to achieve automatic handling of dependencies, and to install all dependent packages at once, without the need to download and install them again and again, front-end tools such as APT and YUM were born.
Debian-based package manager
dpkg
dpkg is an abbreviation for Debian Packager. A package management system developed specifically for Debian to facilitate the installation, update and removal of software. The software is a compiled binary package ending in .deb. All “Linux” distributions derived from “Debian” use “dpkg”, e.g. “Ubuntu “, “Knoppix”, etc.
Common commands.
|
|
apt
APT (known as Advanced Packaging Tools) is the Linux equivalent of YUM, a package installation tool. apt-get, apt-cache and apt-cdrom are command-line tools that handle packages. apt-get, apt-cache and apt-cdrom are command-line tools for processing packages.
Common commands.
|
|
Difference between apt and apt-get commands
One of the notable new features introduced with the release of Ubuntu 16.04 was the introduction of the apt command. In fact, the first stable version of the apt command was released as early as 2014, but it was not until the Ubuntu 16.04 system release in 2016 that it started to attract attention. As the apt install package command became more frequent and common than the apt-get install package, more and more other Linux distributions started to follow in Ubuntu’s footsteps and encouraged users to use apt instead of apt-get. What is the difference between apt-get and apt commands? If they have a similar command structure, why do we need the new apt command? Is apt really better than apt-get? Should the average user use the new apt command or stick with the old habit of using apt-get?
Before we start comparing apt and apt-get, let’s look at the background of these two commands and what they are trying to accomplish. Debian uses a set of tools called Advanced Packaging Tool (APT) to manage this package system, but don’t confuse it with the apt command, they are not really the same thing. In Debian-based Linux distributions, there are various tools that interact with the APT to facilitate the installation, removal, and management of packages. apt-get is one of the popular command-line tools, and another popular one is Aptitude, a small command-line and GUI tool.
If you’ve read the apt-get command guide, you’ve probably encountered many similar commands such as apt-cache, apt-config, and so on. As you can see, these commands are relatively low-level and contain many functions that the average Linux user will probably never use. To put it another way, the most commonly used Linux package management commands are scattered among apt-get, apt-cache, and apt-config. apt was introduced to solve the problem of scattered commands by including the most widely used feature options since the apt-get command came out, as well as apt-cache and apt-config, which are rarely used. apt-config commands. When using the apt command, users no longer have to go from apt-get to apt-cache or apt-config, and apt is more structured and provides users with the necessary options needed to manage packages. Simply put, apt = a collection of the most commonly used command options in apt-get, apt-cache, and apt-config.
With the apt command, the user has all the necessary tools in one place. apt’s main purpose is to provide an efficient way to work with Linux packages in a way that “makes the end user happy”. apt has a more reduced but sufficient set of command options, and the parameter options are organized in a more efficient way. In addition, it has several features that are enabled by default that are very helpful to end-users. For example, you can see a progress bar when installing or removing programs using the apt command. apt also prompts the user for the number of packages that can be upgraded when updating the repository database. If you use the other command options of apt, you can achieve the same thing as when you use apt-get.
Although apt has some similar command options to apt-get, it is not fully backward compatible with the apt-get command. That is, apt can be used to replace some, but not all, of the apt-get family of commands.
apt command | Replaced command | Command function |
---|---|---|
apt install | apt-get install | install packages |
apt remove | apt-get remove | removes packages |
apt purge | apt-get purge | Remove packages and configuration files |
apt update | apt-get update | refresh the repository index |
apt upgrade | apt-get upgrade | upgrade all upgradeable packages |
apt autoremove | apt-get autoremove | automatically remove unneeded packages |
apt full-upgrade | apt-get dist-upgrade | Automatically handle dependencies when upgrading packages |
apt search | apt-cache search | search for applications |
apt show | apt-cache show | show installation details |
Of course, apt has a few commands of its own.
New apt commands | Command functions |
---|---|
apt list | list packages that contain conditions (installed, upgradeable, etc.) |
apt edit-sources | edits the list of sources |
Note that the apt command is still evolving, so you may see new options in future releases.
There is no official word yet from any Linux distribution that apt-get will be discontinued, at least it has more and more fine-grained operations than apt. For low-level operations, you still need apt-get, and since both commands are useful, should I use apt or apt-get? As a regular Linux user, it is recommended that you get used to apt and start using it first, not only because it is recommended by Linux publishers, but also because it provides the necessary options for Linux package management. Most importantly, the apt command has fewer options and is easier to remember and therefore easier to use, so there is no reason to stick with apt-get.
Package manager based on RPM package format
rpm
RPM Package Manager (RPM for short, known as The RPM Package Manager or Redhat Package Manager) is a package manager widely used under Linux. Distributions that use RPM.
- Fedora and Red Hat Enterprise Linux
- openSUSE and SUSE Linux Enterprise
- Mandriva Linux and Mageia
- PCLinuxOS
RPM packages are divided into three types: Binary, Source and Delta packages. Binary packages can be installed directly on your computer, while source packages will be compiled and installed automatically by RPM. RPM is only available for installing software packaged with RPM and is currently one of the most resourceful package types for GNU/Linux.
Common commands for rpm.
|
|
yum
yum is a backend program for managing rpm packages, written in python, which makes it very easy to resolve rpm dependencies. After setting up a yum server, yum clients can get packages via http, ftp, and use convenient commands to directly manage and update all rpm packages, even kernel updates.
Common commands for yum.
|
|
Queries related.
|
|
dnf
DNF is a new generation of rpm package manager. It first appeared in Fedora 18 distribution and recently replaced yum as the package manager for Fedora 22. DNF package manager overcomes some of the bottlenecks of YUM package manager and improves many things including user experience, memory usage, dependency analysis, speed, etc. DNF uses RPM, libsolv and hawkey libraries for package management operations. Although it is not pre-installed in CentOS and RHEL 7, you can use DNF in conjunction with YUM.
Common commands for dnf.
|
|
Differences between DNF and Yum
Many long-standing issues in Yum remain unresolved, including poor performance, excessive memory usage, and slow dependency resolution. Therefore, the Yum package manager has been replaced by the DNF package manager.
Number | DNF (Dandified YUM) | YUM (Yellowdog Updater, Modified) |
---|---|---|
1 | DNF uses libsolv to resolve dependencies and is developed and maintained by SUSE | YUM uses a public API to resolve dependencies |
2 | API is fully documented | API is not fully documented |
3 | Written in C, C++, Python | Written in Python only |
4 | DNF is currently used in Fedora, RHEL 8, CentOS 8, OEL 8, and Mageia 6/7 | YUM is currently used in RHEL 6/7, CentOS 6/7, OEL 6/7 |
5 | DNF supports various extensions | Yum only supports Python based extensions |
6 | The API is well documented, so it’s easy to create new features | It’s very difficult to create new features because the API is not properly documented |
7 | DNF uses less memory when synchronizing the repository’s metadata | YUM uses too much memory when synchronizing the repository’s metadata |
8 | DNF uses a satisficing algorithm to resolve dependency resolution (it uses a dictionary approach to store and retrieve package and dependency information) | Yum dependency resolution becomes sluggish due to the use of a public API |
9 | Dependency resolution performs well in terms of both memory usage and repository metadata | Overall, underperforms due to many factors |
10 | DNF updates: during DNF updates, packages are not updated if they contain irrelevant dependencies | YUM will update packages without validation |
11 | If an enabled repository is not responding, DNF will skip it and continue to use the available repositories for transactions | YUM will stop immediately if a repository is not available |
12 | dnf update and dnf upgrade are equivalent | not in Yum |
13 | Dependencies of installed packages are not updated | Yum provides an option for this behavior |
14 | Clean up deleted packages: When a package is deleted, DNF automatically removes any dependencies that are not explicitly installed by the user | Yum does not do this |
15 | Repository cache update schedule: By default, DNF checks for updates to the configured repositories once an hour, 10 minutes after the system starts. This action is controlled by the system timer unit dnf-makecache.timer | Yum will also do this |
6 | Kernel packages are not protected by DNF. Unlike Yum, you can delete all kernel packages, including running kernel packages | Yum does not allow you to delete running kernels |
17 | libsolv: Used for unpacking and reading repositories. hawkey: Provides a simplified C and Python API library for libsolv. librepo: Provides a C and Python (libcURL-like) API library for downloading Linux repository metadata and packages. libcomps: Is a replacement for the yum.comps library. It is a library written in pure C, with Python 2 and Python 3 bindings. | Yum does not use separate libraries to perform these functions |
18 | DNF contains 29,000 lines of code | Yum contains 56,000 lines of code |
19 | DNF was developed by Ales Kozumplik | YUM was developed by Zdenek Pavlas, Jan Silhan and team members |
zypp
Zypper is another package manager used to manage RPM packages. This package manager is mainly used for SUSE (and openSUSE), but is also used on MeeGo, Sailfish OS, and Tizen. It was originally developed in 2006 and has gone through several iterations. There is not much to say about it except that it serves as a backend for the system management tool YaST and that some users consider it faster than YUM.
Common commands for zyppd.
|
|
urpmi
urpmi is a package management system for Mageia/MandrivaLinux and its derivative distributions for installing, removing, upgrading and querying packages locally or remotely (i.e., the server providing the packages). It solves the problem that RPM package administrators tend to make users encounter interdependency hell on a regular basis. It can obtain packages from official or unofficial sources (unofficial sources such as Penguin Liberation Front). It has a graphical front-end: Rpmdrake. Besides being used by MandrivaLinux, it is also used in MageiaLinux (a derivative version based on MandrivaLinux), and ROSALinux (also a branch based on MandrivaLinux).
The urpmi family of commands.
|
|
The main urpmi configuration file.
Arch-based package managers
Arch Linux uses a package manager called pacman. Unlike .deb and .rpm, it uses the more traditional LZMA2 package form .tar.xz. This allows Arch Linux packages to have a smaller size than other forms of compression, such as gzip. Since its first release in 2002, pacman has been steadily released and improved. One of the biggest benefits of using it is that it supports the Arch Build System, a build system that builds packages from the source level. The build system relies on a file called PKGBUILD, which contains metadata such as version numbers, release numbers, dependencies, etc., as well as a script with the necessary compilation options needed to compile packages that adhere to Arch Linux requirements. The result of this compilation is the .tar.xz file used by pacman as mentioned earlier.
This system technically led to the creation of the Arch User Respository (AUR), a community-driven software repository that contains PKGBUILD files and support patches or scripts. This has given Arch Linux an endless supply of software resources. The most obvious advantage is that if a user (or developer) wants to make his software available to the general public, he does not have to go through the official route of obtaining a license from a mainstream repository. The downside is that it will have to rely on community processes, similar to Docker Hub, Canonical’s Snap Packages, or other similar mechanisms. There are many AUR-specific package managers that can be used to download, compile, and install PGKBUILD files from the AUR.
Using pacman and official repositories
Arch’s main package manager, pacman, uses identifiers rather than command words like yum or apt. For example, to search for a package, you would use pacman -Ss. As with other commands on Linux, you can find pacman’s manual page and online help. pacman uses the sync (-S) identifier bit for most of its commands.
|
|