Package manager

Ubuntu Software Center, example of a package manager

A package manager or package management system is a collection of software tools that automates the process of installing, upgrading, configuring, and removing computer programs for a computer's operating 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 are based on Linux and other Unix-like systems, typically consisting of hundreds or even tens of thousands of distinct software packages.[1]

Functions

Illustration of a package manager being used to download new software. Manual actions can include accepting a license agreement or selecting some package-specific configuration options.

A software package is an archive file containing a computer program as well as necessary metadata for its deployment. The computer program can be in source code that has to be compiled and built first.[2] Package metadata include package description, package version, and dependencies (other packages that need to be installed beforehand).

Package managers are charged with the task of finding, installing, maintaining or uninstalling software packages upon the user's command. Typical functions of a package management system include:

Challenges with shared libraries

Computer systems which rely on dynamic library linking, instead of static library linking, share executable libraries of machine instructions across packages and applications. In these systems, complex relationships between different packages requiring different versions of libraries results in a challenge colloquially known as "dependency hell". On Microsoft Windows systems, this is also called "DLL hell" when working with dynamically linked libraries. Good package management is vital on these systems.[3] The Framework system from OPENSTEP was an attempt at solving this issue, by allowing multiple versions of libraries to be installed simultaneously, and for software packages to specify which version they were linked against.

Front-ends for locally compiled packages

System administrators may install and maintain software using tools other than package management software. For example, a local administrator may download unpackaged source code, compile it, and install it. This may cause the state of the local system to fall out of synchronization with the state of 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 available to ensure that locally compiled packages are integrated with the package management. For distributions 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

Particularly troublesome with software upgrades are upgrades of configuration files. Since package managers, at least on Unix systems, originated as extensions of file archiving utilities, they can usually only either overwrite or retain configuration files, rather than applying rules to them. There are exceptions to this that usually apply to kernel configuration (which, if broken, will render the computer unusable after a restart). Problems can be caused if the format of configuration files changes. For instance, if the old configuration 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, it is desirable to install packages with the default configuration and then overwrite this configuration, for instance, 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 kinds of software that they are allowing to be installed on their system (and sometimes due to legal or convenience reasons on the distributors' side), software is often downloaded from a number of software repositories.[4]

Upgrade suppression

When a user interacts with the package management software to bring about an upgrade, it is customary to present the user with the list of things to be done (usually the list of packages to be upgraded, and possibly giving the old and new version numbers), and allow the user to either accept the upgrade in bulk, or select individual packages for upgrades. 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 sometimes called version pinning.

For instance:

Cascading package removal

Some of the more advanced package management features offer "cascading package removal",[6] in which all packages that depend on the target package and all packages that only the target package depends on, are also removed.

Comparison of commands

Although the commands are specific for every particular package manager, they are to a large extent translatable, as most package managers offer similar functions.

Action Pacman apt(-get) rpm/yum Portage
install package pacman -S PACKAGE apt install PACKAGE yum install PACKAGE emerge PACKAGE
remove package pacman -R PACKAGE apt remove PACKAGE yum --nodeps remove PACKAGE emerge -C PACKAGE or
emerge --unmerge PACKAGE
remove package+dependencies apt autoremove PACKAGE yum remove PACKAGE emerge -c PACKAGE or
emerge --depclean PACKAGE
update software database pacman -Syy apt update emerge --sync
show updatable packages pacman -Qu apt list --upgradable emerge -avtuDN --with-bdeps<nowiki>=</nowiki>y @world or
emerge --update --pretend @world
delete orphans+config pacman -Rsn $(pacman -Qdtq) apt autoremove emerge --depclean
show orphans pacman -Qdt emerge -caD or
emerge --depclean --pretend
update all pacman -Syu apt upgrade emerge --update --deep --with-bdeps<nowiki>=</nowiki>y @world

Arch's Pacman/Rosetta-page offers an extensive overview.[9]

Prevalence

Linux distributions 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-like) and Windows Phone rely almost exclusively on their respective vendors' app stores and thus use their own dedicated package management systems.

Comparison with installers

A package manager is often called an "install manager", which can lead to a confusion between package managers and installers. The differences include:

Criterion Package manager Installer
Shipped with Usually, the operating system Each computer program
Location of installation information One central installation database It is entirely at the discretion of the installer. It could be a file within the app's folder, or among the operating system's files and folders. At best, they may register themselves with an uninstallers list without exposing installation information.
Scope of maintenance Potentially all packages on the system Only the product with which it was bundled
Developed by One package manager vendor Multiple installer vendors
Package format One or two well-known formats There could be as many formats as the number of apps
Package format compatibility Can be consumed as long as the package manager supports it. Either newer versions of the package manager keep supporting it or the user does not upgrade the package manager. The installer is always compatible with its archive format, if it uses any. However, installers, like all computer programs, may be affected by software rot.

Comparison with build automation utility

Most software configuration management system 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 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. For example, the dependency graph topological sorting used in a package manager to handle dependencies between binary components is also used in a build manager to handle the dependency between source components. For example, many makefiles support not only building executables, but also installing them with make install. For example, every package manager for a source-based distribution – Portage, Sorcery, Homebrew, etc. – supports converting human-readable source code to binary executables and installing it.

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.[10]

Common package managers and formats

Universal package manager

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.[11] 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.[12]

Common universal package managers are Jfrog's Artifactory and Inedo's ProGet.

Package formats

Main articles: Package format and file archive

Each package manager relies on the format and metadata of the packages it can manage. That is, package managers need groups of files to be bundled for the specific package manager along with appropriate metadata, such as dependencies. Often, a core set of utilities manages the basic installation from these packages and multiple package managers use these utilities to provide additional functionality.

For example, yum relies on rpm as a backend. Yum extends the functionality of the backend by adding features such as simple configuration for maintaining a network of systems. As another example, the Synaptic Package Manager provides a graphical user interface by using the Advanced Packaging Tool (apt) library, which, in turn, relies on dpkg for core functionality.

Alien is a program that converts between different Linux package formats, supporting conversion between Linux Standard Base (LSB) compliant .rpm packages, .deb, Stampede (.slp), Solaris (.pkg) and Slackware (.tgz, .txz, .tbz, .tlz) packages.

In mobile operating systems, Google Play consumes Android application package (APK) package format while Windows Store uses APPX and XAP formats. (Both Google Play and Windows Store have eponymous package managers.)

Free and open source software systems

By the nature of free and open source software, packages under similar and compatible licenses are available for use on a number of operating systems. These packages can be combined and distributed using configurable and internally complex packaging systems to handle many permutations of software and manage version-specific dependencies and conflicts. Some packaging systems of free and open source software are also themselves released as free and open source software. One typical difference between package management in proprietary operating systems, such as Mac OS X and Windows, and those in free and open source software, such as Linux, is that free and open source software systems permit third-party packages to also be installed and upgraded through the same mechanism, whereas the package managers of Mac OS X and Windows will only upgrade software provided by Apple and Microsoft, respectively (with the exception of some third party drivers in Windows). The ability to continuously upgrade third party software is typically added by adding the URL of the corresponding repository to the package management's configuration file.

Application-level package managers

Beside the system-level application managers, there are some add-on package managers for operating systems with limited capabilities and for programming languages in which developers need the latest libraries.

In contrast to system-level application managers, application-level package managers focus on a small part of the software system. They typically reside within a directory tree that is not maintained by the system-level package manager, such as c:\cygwin or /usr/local/fink. However, this might not be the case for the package managers that deal with programming libraries, leading to a possible conflict as both package managers may claim to "own" a file and might break upgrades.

Impact

Ian Murdock has 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".[13]

See also

References

  1. ↑ "Software Distribution". Dell KACE. Retrieved 2012-07-11.
  2. ↑ Ludovic Courtès, Functional Package Management with Guix, June 2013, Madrid, European Lisp Symposium 2013 ;
  3. ↑ Chris, Tucker (2007-03-15). "Optimal Package Install/Uninstall Manager" (PDF). UC San Diego: 1. Retrieved 2011-09-14.
  4. ↑ "Linux repository classification schemes". braintickle.blogspot.com. Retrieved 2008-03-01.
  5. ↑ "CentOS yum pinning rpms". centos.org. Archived from the original on 2007-11-02. Retrieved 2008-03-01.
  6. 1 2 "pacman(8) Manual Page". archlinux.org. Retrieved 2008-03-01.
  7. ↑ "How to keep specific versions of packages installed (complex)". debian.org. Retrieved 2008-03-01.
  8. ↑ "Apt pinning to blacklist a package". Retrieved 2010-08-19.
  9. ↑ https://wiki.archlinux.org/index.php/Pacman/Rosetta
  10. ↑ Eelco Dolstra. "Integrating Software Construction and Software Deployment".
  11. ↑ Waters, John K. (8 September 2015). "JFrog Releases 'Universal' Artifact Repository". ADT Mag. Application Development Trends Magazine.
  12. ↑ Decoster, Xavier (18 August 2013). "An Overview of the NuGet Ecosystem". CodeProject.com.
  13. ↑ "How package management changed everything". ianmurdock.com. Retrieved 2008-03-01.
This article is issued from Wikipedia - version of the 11/20/2016. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.