Package manager
A package manager, or package management system, is software that supports installing, upgrading, configuring, and removing software for the host system in a consistent manner.
A package manager deals with packages, distributions of software and data in archive files. Packages contain metadata, such as the software's name, description of its purpose, version number, vendor, checksum, and a list of dependencies necessary for the software to run properly. Upon installation, metadata is stored in a local package database. Package managers typically maintain a database of software dependencies and version information to prevent software mismatches and missing prerequisites. They work closely with software repositories, binary repository managers, and app stores.
Package managers are designed to eliminate the need for manual installs and updates. This can be particularly useful for large enterprises whose operating systems typically consist of hundreds or even tens of thousands of distinct packages.
History
An early package manager was SMIT from IBM AIX. SMIT was introduced with AIX 3.0 in 1989. Package managers like dpkg have existed as early as 1994. Early package managers, from around 1994, had no automatic dependency resolution but could already simplify the process of adding and removing software from a running system.By around 1995, beginning with CPAN, package managers began handling package repository downloads, and dependency resolution and installation as needed, making it easier to install, uninstall and update software.
Functions
A software package is an archive file containing a computer program as well as necessary metadata for its deployment. The program may be in source code that has to be compiled and built first. Package metadata include the software's description, version number, and dependencies.Package managers are charged with the task of finding, installing, maintaining or uninstalling packages upon the user's command. Typical functions of a package management system include:
- Using file archivers to extract package archives
- Ensuring the integrity and authenticity of the package by verifying their checksums and digital certificates, respectively
- Looking up, downloading, installing, or updating existing software from a software repository or app store
- Grouping packages by function to reduce user confusion
- Managing dependencies to ensure a package is installed with all the packages it requires, and avoiding ''dependency hell''
Challenges with shared libraries
Modern package managers have mostly solved these problems by allowing parallel installation of multiple library versions, a dependency of any kind, and even packages compiled with different compiler versions, in order to enable other packages to specify which version they are linked or installed against.
Front-ends for locally-compiled packages
s may install and maintain software using tools other than package managers. For example, a local administrator may download unpackaged source code, compile it, and install it. This may cause the local system to fall out of synchronization with the package manager's database. The local administrator will be required to take additional measures, such as manually managing some dependencies or integrating the changes into the package manager.There are tools to ensure that locally-compiled packages are integrated with the package management. For operating systems based on.deb and.rpm files as well as Slackware Linux, there is CheckInstall, and for recipe-based systems such as Gentoo Linux and hybrid systems such as Arch Linux, it is possible to write a recipe first, which then ensures that the package fits into the local package database.
Maintenance of configuration
s of configuration files may be particularly troublesome. Since package managers, at least on Unix systems, originated as extensions of file archivers, they can usually only overwrite or retain configuration files, rather than apply rules to them. There are exceptions to this that usually apply to kernel configuration. Problems can be caused if the configuration file format changes; for instance, if the old file does not explicitly disable new options that should be disabled. Some package managers, such as Debian's dpkg, allow configuration during installation. In other situations, packages are installed with the default configuration, which is then overwritten, for example in headless installations to a large number of computers. This kind of pre-configured installation is also supported by dpkg.Repositories
To give users more control over the software they allow to be installed on their systems, and sometimes due to legal or convenience reasons on the distributors' side, packages are often downloaded from software repositories.Upgrade suppression
When a user is upgrading a package with package management software, it is customary for them to be presented with the actions to be executed, and allow them to either accept the upgrade in bulk, or select individual packages for upgrading. Many package managers can be configured to never upgrade certain packages, or to upgrade them only when critical vulnerabilities or instabilities are found in the previous version, as defined by the packager of the software. This process is called upgrade suppression, or version pinning. For instance, to prevent upgrades to the OpenOffice program:- yum supports upgrade suppression with the syntax
exclude=openoffice* - pacman with
IgnorePkg= openoffice - dpkg and dselect support partial suppression through the hold flag in package selections
- APT extends the hold flag through a pinning mechanism, and users can also blacklist a package
- aptitude uses hold and forbid flags
- portage supports suppression through the package.mask configuration file
Cascading package removal
Comparison of commands
Although commands are specific to each package manager, they are translatable to a large extent, as most package managers offer similar functions. The Arch Linux wiki offers an extensive overview of commands.| Action | Homebrew | APT | Pacman | dnf | portage | zypper | Nix | XBPS | swupd | WinGet |
| Install package | ||||||||||
| Remove package | or | |||||||||
| Update software database | or | |||||||||
| Show updatable packages | or | or | ||||||||
| Update all | ||||||||||
| Delete orphans and config | ||||||||||
| Show orphans | or | |||||||||
| Remove package | or |
Prevalence
s oriented to binary packages rely heavily on package management systems as their primary means of managing and maintaining software. Mobile operating systems such as Android and iOS rely almost exclusively on their respective vendors' app stores and thus use their own dedicated package management systems.Similar programs and platforms
Installers
A package manager is often called an install manager, which can lead to a confusion between package managers and installers. The differences include:Build automation utilities
Most software configuration management systems treat building software and deploying software as separate, independent steps. A build automation utility typically takes human-readable source code files already on a computer, and automates the process of converting them into an executable package on the same or a remote computer. Later, a package manager typically running on another computer downloads the pre-built executable and installs it.However, both kinds of tools have many commonalities:
- Topological sorting of the dependency graph used in a package manager to handle dependencies between binary components is also used in a build manager to handle dependencies between source components.
- Many makefiles support not only building executables, but also installing them with
make install. - Every package manager for a source-based distributionsuch as Portage, Sorcery, or Homebrewsupports converting source code to binary executables and installing it.