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 (preferably a cryptographic hash function), 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 software packages.[2]
History[edit]
An early package manager was SMIT (and its backend installp) from IBM AIX. SMIT was introduced with AIX 3.0 in 1989.
Early package managers, from around 1994, had no automatic dependency resolution[3] but could already drastically simplify the process of adding and removing software from a running system.[4]
By around 1995, beginning with CPAN, package managers began doing the work of downloading packages from a repository, automatically resolving its dependencies and installing them as needed, making it much easier to install, uninstall and update software from a system.[5]
pacman, a CLI utility for Arch-based distributions
Package managers like dpkg have existed as early as 1994.[17]
Linux distributions 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 (Linux-based), iOS (Unix-based), and Windows Phone rely almost exclusively on their respective vendors' app stores and thus use their own dedicated package management systems.
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 a binary executable package on the same or remote computer.
Later a package manager typically running on some other computer downloads those pre-built binary executable packages over the internet and installs them.
However, both kinds of tools have many commonalities:
A few tools, such as Maak and A-A-P, are designed to handle both building and deployment, and can be used as either a build automation utility or as a package manager or both.[18]
Comparison with app stores[edit]
App stores can also be considered application-level package managers, without the ability to install all levels of programs[19][20]). Unlike traditional package managers, app stores are designed to enable payment for the software itself (instead of for software development), and may only offer monolithic packages with no dependencies or dependency resolution.[21][20] They are usually extremely limited in their management functionality, due to a strong focus on simplification over power or emergence, and common in commercial operating systems and locked-down “smart” devices.
Package managers also often have only human-reviewed code. Many app stores, such and Google Play and Apple's App Store, screen apps mostly using automated tools only; malware with defeat devices can pass these tests, by detecting when the software is being automatically tested and delaying malicious activity.[22][23][24] There are, however, exceptions; the npm package database, for instance, relies entirely on post-publication review of its code,[25][26] while the Debian package database has an extensive human review process before any package goes into the main stable database. The XZ Utils backdoor used years of trust-building to insert a backdoor, which was nontheless caught while in the testing database.
Common package managers and formats[edit]
Universal package manager[edit]
Also known as binary repository manager, it is a software tool designed to optimize the download and storage of binary files, artifacts and packages used and produced in the software development process.[27] These package managers aim to standardize the way enterprises treat all package types. They give users the ability to apply security and compliance metrics across all artifact types. Universal package managers have been referred to as being at the center of a DevOps toolchain.[28]
Impact[edit]
Ian Murdock had commented that package management is "the single biggest advancement Linux has brought to the industry", that it blurs the boundaries between operating system and applications, and that it makes it "easier to push new innovations [...] into the marketplace and [...] evolve the OS".[32]
There is also a conference for package manager developers known as PackagingCon. It was established in 2021 with the aim to understand different approaches to package management.[33]