Jump to content

Package manager

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Bcornec (talk | contribs) at 01:20, 27 April 2010 (project-builder.org added again, without its dedicated page this time as that information is relevant to this page). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Illustration of a package management system being used to download new software. A typical manual action requested is restarting the computer.
Synaptic, one of the most widely used graphical frontends for package management in Linux
Aptitude, a package management system, resolving the dependencies of ldm, a software package selected for installation.

A package management system is a collection of tools to automate the process of installing, upgrading, configuring, and removing software packages from a computer. Distributions of Linux and other Unix-like systems typically consist of hundreds or even thousands of distinct software packages; in the former case a package management system is nice, in the latter case it is essential.

Packages are distributions of software and metadata such as the software's full 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.

A package management system provides a consistent method of installing software. A package management system is sometimes incorrectly referred to as an installer.

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".[1]

Terminology

A package management system is often called an "install manager". This can lead to confusion between a package management system and an installer. The differences include:

This box:
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 A handful of 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.

A package, for package managers, denotes a specific set of files bundled with the appropriate metadata for use by a package manager. This can be confusing, as some programming languages often use the word "package" as a specific form of software library. Furthermore, that software library can be distributed in a package of files bundled for a package manager.

Functions

Package management systems are charged with the task of organizing all of the packages installed on a system and maintaining their usability. Typical functions of a package management system include:

  • Verifying file checksums to ensure correct and complete packages.
  • Verifying digital signatures to authenticate the origin of packages.
  • Applying file archivers to manage encapsulated files.
  • Upgrading software with latest versions, typically from a software repository.
  • Grouping of packages by function to help eliminate user confusion.
  • Managing dependencies to ensure a package is installed with all packages it requires.

Some additional challenges are met by only a few package management systems.

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 systems become vital on these systems.

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.[citation needed]

Maintenance of configuration

Particularly troublesome with software upgrades are upgrades of configuration files. Since package management systems, 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 management systems, 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

In order 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.[2]

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 management systems 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:

  • yum supports this with the syntax exclude=openoffice*,[3] pacman with IgnorePkg = openoffice[4] (to suppress upgrading openoffice in both cases)
  • dpkg and dselect support this partially through the hold flag in package selections
  • APT extends the hold flag through the complex "pinning" mechanism[5]
    • You even can blacklist a package[6]
  • aptitude has "hold" and "forbid" flags
  • portage supports this through the package.mask configuration file

Cascading package removal

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

Common package management systems and formats

Package formats

Main articles: Linux package formats 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. It supports conversion between Linux Standard Base conform RPM, deb, Stampede (.slp) and Slackware (tgz) packages.

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 PMS 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.

Binary installation / Precompiled packages

Linux distributions
Mac OS X
  • fink, for Mac OS X, derives partially from dpkg/apt and partially from ports.
  • MacPorts, formerly called DarwinPorts, originated from the OpenDarwin project.
  • Homebrew, with a fresh approach and close git integration.
iPhone OS
Microsoft Windows
  • Cygwin — a free and open source software repository for the Windows operating system which provides many GNU/Linux tools and an installation tool née package manager.
  • Appsnap — a package manager for Windows written in Python released under the GPL.
  • Appupdater — a package manager for Windows written in Python released under the GPL.
  • Windows-get — a package manager for Windows written in Delphi and PHP released into the public domain.
  • GetIt — uses Appsnap, Appupdater, and Windows-get as sources and combines their repositories into one big catalog. Released under the GPL.
PC-BSD
  • PC-BSD uses files with the .pbi filename extension which, when double-clicked, brings up an installation wizard program. An autobuild system tracks the FreeBSD ports collection and generates new PBI's daily
Solaris
Cross platform

Sourcecode-based installation / Installing using compile scripts

  • Portage and emerge are used by Gentoo Linux. They were inspired by the BSD ports system and use scripts called ebuilds to install software.
  • A recipe file contains information on how to download, unpack, compile and install a package in GoboLinux distribution using its Compile tool.
  • apt-build is used by distributions which use deb packages, allowing automatic compiling and installation of software in a deb source repository.
  • Sorcery is Sourcemage GNU/Linux's bash based package managment program that automatically downloads software from their original site and compiles and installs it on the local machine.
  • ABS is used by Arch Linux to automate binary packages building from source or even other binary archives, with automatic download and dependency checking.

Hybrid systems

Meta package managers

The following unify package management for several or all Linux and sometimes Unix variants. These, too, are based on the concept of a recipe file.

  • Autopackage uses .package files.
  • epm, developed by Easy Software Products (creators of CUPS), is a "meta packager", that allows creation of native packages for all Linux and Unix operating systems (.deb, .rpm, .tgz for Linux, pkg for Solaris and *BSD, .dmg for OS X,...) controlled from a single *.list file.
  • klik aims to provide an easy way of getting software packages for most major distributions without the dependency problems so common in many other package formats.
  • [Project-Builder.org] is a GPL v2 tool designed to help projects developers to easily produce packages for multiple OS's and architectures, on a regular basis and from a single source repository.
  • RUNZ, used in portable applications and SuperDebs for Super OS (formerly: Super Ubuntu)[7].
  • Zero Install installs each package into its own directory and uses environment variables to let each program find its libraries. Package and dependency information is downloaded directly from the software authors' pages in an XML format, similar to an RSS Feed.
  • Nix package manager manages packages in a purely functional way.
  • PackageKit is a set of utilities and libraries for creating applications that can manage packages across multiple package managers using back-ends to call the correct program.

Proprietary software systems

A wide variety of package management systems are in common use today by proprietary software operating systems, handling the installation of both proprietary and free packages.

Application-level package managers

Besides the systems-level application managers, there are some add-on package managers for operating systems with limited capabilities and for programming languages where developers need the latest libraries. Those include the package managers listed for Windows and OS X above, as well as:

In contrast to systems-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 systems-level package manager (like c:\cygwin or /usr/local/fink). However, this is not the case for the package managers that deal with programming libraries. This leads to a conflict as both package managers claim to "own" a file and might break upgrades.

See also

References

  1. ^ "How package management changed everything". ianmurdock.com. Retrieved 2008-03-01.
  2. ^ "Linux repository classification schemes". braintickle.blogspot.com. Retrieved 2008-03-01.
  3. ^ "CentOS yum pinning rpms". centos.org. Retrieved 2008-03-01.
  4. ^ a b "pacman(8) Manual Page". archlinux.org. Retrieved 2008-03-01.
  5. ^ "How to keep specific versions of packages installed (complex)". debian.org. Retrieved 2008-03-01.
  6. ^ "apt pinning to blacklist a package".
  7. ^ RUNZ homepage
Retrieved from "https://en.wikipedia.org/enwiki/w/index.php?title=Package_manager&oldid=358542833"