Linux Package Manager

Introduction

A package management system or package manager is a group of software tools. It automates the installation process, upgrading process, configuration process, and removing process of the computer programs for an operating system of the computer in an efficient manner. A package manager works with packages, data within archive files, and software distributions.

Packages include metadata like the name of the software, description of its objective, checksum (a cryptographic hash function preferably), dependency list, vendor, and version number essential for the software to properly run.

• Metadata is saved inside the database of a local package upon installation.
• Typically, package managers manage the database of the version information and software dependencies for preventing missing prerequisites and software mismatches.
• They operate closely with app stores, binary repository managers, and software repositories.
• Package managers are developed for eliminating the requirement for manual updates and installs.
• Particularly, it can be helpful for large organizations whose OSes are combining hundreds or much more different software packages typically.

Functions of Package Manager

A software package can be defined as the archive file combining a computer program and essential metadata as well for the development. The system program could be within the source code that has to be built and compiled first.

Package metadata contains package version, package description, and dependencies (packages that require to be beforehand installed). Many package managers are owned with the action of installing, uninstalling, maintaining or finding software packages under the command of the user.

The package management system contains some typical functions which are mentioned below:

• Dealing with the file archivers for extracting package archives.
• Assuring the authenticity and integrity of the package by authenticating their digital certificates and checksums respectively.
• Updating, installing, downloading, or looking up existing software through an app store or software repository.
• Combining packages via function for reducing the confusion of the user.
• Maintaining dependencies for ensuring a package has been installed along with every package it needs. So, ignoring "dependency hell".

Front-ends for compiled packages (locally)

System administrators might install and manage the software with the help of some tools other than the software of package management. For example, a local administrator might download the source code (unpackaged), compile it, and then install it.

It may cause the local system state for falling out of the synchronization along with the database of the package manager state. The local administrator would be needed to take some additional measures like manually integrating the modifications into a package manager or managing a few dependencies.

There are some tools present for ensuring that the compile packages (locally) are developed with the package management.

CheckInstall is available for .rpm or .deb file-based distributions and Slackware Linux as well. For hybrid systems like Arch Linux and recipe-based systems like Gentoo Linux, it is possible to initially specify a recipe, which then confirms that a package fits into a local package database.

Challenges with distributed libraries

Various computer systems that depend on the dynamic library linking, rather than static library linking, distribute machine instruction's libraries (executable) across applications and packages.

In these types of systems, the typical relationships between distinct packages needing library result versions in a challenge called "dependency hell".

It is also known as "DLL hell" on Microsoft Windows when dealing with linked libraries dynamically. Good package management is crucial for these systems.

From OPENSTEP, the framework system was a shot at solving this problem, by permitting more than one library version to be simultaneously installed, and for many software packages to describe which version they're linked across.

Configuration Maintenance

The configuration file's upgrades are particularly problematic with software upgrades. At least on Unix, since package managers originated as the file archiving utility extension.

Usually, they only either retain or overwrite the configuration files, instead of using rules to them. Several issues can arise when the configuration file format modifies. For example, if an old configuration file doesn't disable newer options explicitly that must be displayed. A few package managers like Debian's dpkg, permit configuration at the time of installation. In some other cases, it's desirable for installing packages along using the default configuration and overwrite the configuration in installation (headless) to a large number of systems. This type of installation (pre-configured) is supported via dpkg as well.

Upgrade Suppression

It is traditional to available the user along with the action list to be run (usually the package list to be upgraded and provide the new and old version numbers possibly) if a user cooperates with the package management software for bringing about the upgrade.

It permits the user to either select a single package for upgrades or take an upgrade in bulk. Various package managers could be configured for never upgrading many packages, or for upgrading them only if critical instabilities or vulnerabilities are detected in the old standard, as specified by the software package. Sometimes, this process is known as version pinning.

For example:

yum supports it with the exclude=openoffice* syntax

pacman with the syntax Ignore=openoffice (in both the cases, for suppressing upgrading openoffice)

dselect and dpkg support it partially by the hold flag within the package selections.

aptitude has "forbid" and "hold" flags.

portage supports it by a configuration file, i.e., package.mask.

APT extends the flag, i.e., hold by the complex "pinning" method (users can blacklist the package as well).

Repositories

To provide users extra control over the types of software that they're permitting to be installed over their system (sometimes because of the convenience and legal reasons on the side of the distributor), the software is sometimes downloaded using many software repositories.

Cascading package removal

A few of the more developed package management aspects facilitate "cascading package removal", where every package that relies on the destination package and every package that the destination package relies on, are removed also.

Commands comparison

However, the commands are unique for all the specific package managers. These commands are to a big extent translatable because most of the package managers facilitate the same functions.

Prevalence of the Package Manager

Package managers such as dpkg are available as early as 1994. Various distributions of Linux oriented to the binary packages heavily rely on the package management system because of their main means of maintaining and managing software.

Many mobile operating systems like Windows Phone, iOS (Unix-like), and Android (Linux-based) depend almost on their respective App Store of the vendor. Hence, they use their package management system (dedicated).

Comparison with the Installers

Often, a package manager is known as an "install manager". It can cause confusion among installers and package managers. Some of the main differences are given below:

Comparison with automation utility

Almost all the software configuration management systems represent deploying software and building software as separate. Typically, the build automation utility takes the source code files which are in the human-readable format already on a system and it accelerates the procedure of converting them into an executable package (binary) on a similar system.

Typically, a package manager later running on a few other systems downloads those executable packages (pre-built binary) on the Internet and then installs them.

Although, both types of tools include several common factors which are mentioned below:

• The dependency graph topological sorting is applied within a package manager for handling dependencies between many binary components.
• Also, it is applied inside a build manager for handling the dependency between many source components.
• Various makefiles provide their support, not just building executables.
• Also, they support installing the, using make install.
• All package managers support translating source code (human-readable) into binary executables and then install it for the source-based distribution like Homebrew, Sorcery, Portage, etc.

Some tools like A-A-P and Maak are developed to manage both deployment and building. They can also be used as either a package manager or a build automation utility or both.

Basic package managers and their formats

Universal package manager

It is also called binary repository manager. This package manager is a software tool created for optimizing the storage and download the binary files, packages, and artifacts produced and used within a software development process.

Universal package managers focus to standardize the fashion users treat every type of package. They provide users the capability to use compliance and security metrics around each type of artifact. They have been assigned to as being in the middle of a DevOps toolchain.

Open-source and free software systems

The packages upon compatible and similar licenses have existed for use on several operating systems by the behavior of open-source and free software.

These packages could be distributed and combined using internally complex and configurable packaging systems to manage several version-specific conflicts and dependencies and software permutations.

Also, a few packaging systems of open-source and free software are themselves published as open-source and free software.

One difference among package management in operating systems like Windows and Mac OS X and, those in open-source and free software, like Linux is that open-source and free software systems allow third-party packages to be upgraded and installed from a similar mechanism. Whereas, many package managers of Windows and Mac OS X will upgrade software given by Microsoft and Apple respectively.

The capability for continuously upgrading third-party software is added by including the corresponding repository URL to the configuration file of the package management.

Package formats

All package managers depend on the metadata and format of the packages they could manage. Package managers require file groups to be grouped for the particular package manager with proper metadata like dependencies.

A core collection of utilities often manages the general installation through these packages and more than one package manager applies these utilities for providing additional functionality.

Example:

1. yum depends on rpm as the backend. Yum develops the backend functionality by adding aspects like simple configuration to maintain the system network.
2. The synaptic package manager gives a GUI by applying the library of the Advanced Packaging Tool which depends on the dpkg.

Alien can be defined as a program that translates between distinct Linux package formats. It is supporting conversion among Slackware (.tgz, .tlz, .tbz, .txz) packages, Solaris (.pkg), Stampede (.slp), .deb, .rpm packages, and Linux Standard Base (LSB) compliant.

In several mobile OSes such as Google Play utilizes the package format of the Android Application Package (in short APK) while the Windows Store uses the formats of XAP and APPX. Both Windows Store and Google Play contain eponymous package managers.

Application-level package managers

There are a few package managers (add-on) for OSes for programming languages and with restricted capabilities where developers require the current libraries. The application-level package managers concentrate on the software system's small part in contrast to the system-level package managers.

Typically, they reside in a directory tree. It is not organized by a system-level package manager like /usr/local/fink or c:\cygwin. Although, it may not be the condition for a package manager that works with programming libraries, causing a possible conflict as both of the package managers may break upgrades and request to "own" the file.