You get a bonus - 1 coin for daily activity. Now you have 1 coin

Package Managers: Composer, npm, pip, Maven, apt and Homebrew

Lecture



A package manager — is a program that automatically installs, updates and removes libraries or applications together with their dependencies.

A package manager, or package management system, is software that provides a consistent way to install, update, configure and remove software on a host system.

A package manager works with packages — software distributions and data bundled in archive files. Packages contain metadata such as the software name, a description of its purpose, the version number, the vendor, a checksum (usually a cryptographic hash) and a list of dependencies required for the software to work correctly. Once installed, the metadata is stored in a local package database. Package managers typically maintain a database of software dependencies and version information in order 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 installation and updating. This can be especially valuable for large enterprises, whose operating systems (OS) typically consist of hundreds or even tens of thousands of distinct packages.

A comparison table of popular package managers: Composer, npm, pip, Apache Maven, APT and Homebrew

Characteristic Composer npm pip Maven apt Homebrew
Primary language

PHP

Package Managers: Composer, npm, pip, Maven, apt and Homebrew

JavaScript / Node.js

Package Managers: Composer, npm, pip, Maven, apt and Homebrew

Python

Package Managers: Composer, npm, pip, Maven, apt and Homebrew

Java

Package Managers: Composer, npm, pip, Maven, apt and Homebrew

Any system packages (Linux)

Package Managers: Composer, npm, pip, Maven, apt and Homebrew

System packages (macOS/Linux)

Package Managers: Composer, npm, pip, Maven, apt and Homebrew

Package type PHP libraries JS packages and tools Python libraries Java dependencies and projects System programs CLI utilities and applications
Configuration file composer.json package.json requirements.txt / pyproject.toml pom.xml sources.list Brewfile (optional)
Installing a package composer require npm install pip install entry in pom.xml + mvn install apt install brew install
Dependency resolution Yes Yes Yes Yes (very strict) Yes Yes
Version management semver semver PyPI versions strict versions repository versions formula versions
Global installation Limited Yes (-g) Yes Usually not needed Yes Yes
Area of use PHP projects Frontend/Node Python development Java projects System management Developer utilities
Runs on Linux, macOS, Windows Linux, macOS, Windows Linux, macOS, Windows Linux, macOS, Windows Debian/Ubuntu and others macOS, Linux
Default repository Packagist npm registry PyPI Maven Central Debian repos Homebrew core
Support for multiple versions of the same package - Yes - - - Partially
Where packages are stored vendor/ inside the project node_modules/ (nested) Virtual environment (venv) Local repository + project /usr/lib, /usr/bin /usr/local/Cellar or /opt/homebrew
Where packages come from packagist.org npm Registry npmjs.com PyPI pypi.org Maven Central central.sonatype.com

Debian Repository

debian.org/distrib/packages

Homebrew Core

GitHub

URL: github.com/Homebrew/homebrew-core

Custom repositories Yes (VCS, URL) Yes (registry URL) Yes (--index-url) Yes (repositories) yes, by adding an entry to sources.list Yes (tap)
Local paths yes local tarball yes yes yes, by adding an entry to sources.list yes
Installation over FTP yes no yes, possible via --index-url yes, by adding an entry to sources.list no, only Git / HTTP(S) tap
Free hosting for public packages? Yes Yes Yes Yes Yes Yes
Paid package hosting Via private repos Yes (private packages) Not directly Not directly Usually no No
Limits 50–100 MB ~100 MB per package 100 MB per archive, 512 MB per linked file ~100 MB per JAR / POM

No hard limit,

but overly large

.deb packages (>500 MB) are discouraged

Usually < 100 MB
Alternative managers satis, private-packagist yarn, pnpm pipenv, poetry Gradle, Ivy aptitude, nala, Snap, Flatpak and AppImage MacPorts, Nix

Package Managers: Composer, npm, pip, Maven, apt and Homebrew

Imagine you are writing a program and you need a library.
Without a package manager you would have to:

  • find the website
  • download the archive
  • unpack it
  • wire up the dependencies
  • check the versions

With a package manager it takes a single command:

npm install react

or

pip install requests

And that is all

What a package manager can do

Core features:

  • installing packages
  • updating packages
  • removing packages
  • installing dependencies automatically
  • keeping a list of the project's dependencies
  • pinning versions for reproducibility

An example

You install a single library:

composer require monolog/monolog

But the package manager will:

  • download it
  • find its dependencies
  • download those as well
  • check compatibility

Types of package managers

  1. For programming languages
    • npm — JavaScript
    • pip — Python
    • Composer — PHP
  2. For the system
    • APT — Linux
    • Homebrew — macOS
  3. For building projects
    • Apache Maven — Java

A package manager is an automatic installer for libraries and applications along with their dependencies.

History of package managers

One of the earliest package managers was SMIT (and its installation backend) from IBM AIX. SMIT was introduced together with AIX 3.0 in 1989. Package managers such as dpkg have existed since as early as 1994. The early package managers that appeared around 1994 had no automatic dependency resolution, but they already simplified the process of adding and removing software on a running system.

From roughly 1995 onwards, starting with CPAN, package managers began handling downloads from package repositories as well as dependency resolution and installation as needed, which made installing, removing and updating software much easier.

How package managers work and what they are for

Package Managers: Composer, npm, pip, Maven, apt and Homebrew
An illustration of using a package manager to download new software. Steps performed manually may include accepting a software license agreement or choosing package-specific configuration options.

A software package is an archive file containing a computer program along with the metadata required to deploy it. The program may be in source code form, which first has to be compiled and built. Package metadata includes a description of the software, the version number and the dependencies.

Package managers are responsible for finding, installing, maintaining or removing packages on the user's command. Typical features of a package management system include:

  • Using file archivers to extract package archives.
  • Ensuring the integrity and authenticity of a package by verifying its checksums and digital certificates respectively.
  • Finding, downloading, installing or updating existing software from a software repository or app store.
  • Grouping packages by function to reduce confusion among users.
  • Managing dependencies so that a package is installed with everything it needs and dependency-related problems are avoided.

Challenges with shared libraries

Computer systems that use dynamic linking instead of static linking share executable libraries of machine instructions across different packages and applications. In such systems, conflicting relationships between different packages requiring different library versions lead to a situation known as «dependency hell». On Microsoft Windows systems this is also called «DLL hell» when dealing with dynamically linked libraries.

Modern package managers have largely solved these problems by allowing several library versions to be installed side by side (for example, the OPENSTEP framework system), dependencies of any kind (for example, slots in Gentoo Portage), and even packages compiled with different compiler versions (for example, dynamic libraries produced by the Glasgow Haskell Compiler, for which no stable ABI exists), so that other packages can specify which version they are linked against or installed with.

Front-ends for locally compiled packages

System administrators may install and maintain software using tools other than package managers. For example, a local administrator can download unpackaged source code, compile it and install it. This can leave the local system out of sync with the package manager database. The local administrator would then have to take extra steps, such as managing some dependencies manually or integrating the changes into the package manager.

Tools exist that integrate locally compiled packages with the package management system. For operating systems based on .deb and .rpm files, as well as for Slackware Linux, there is CheckInstall; and for recipe-based systems such as Gentoo Linux and hybrid systems such as Arch Linux, you can first write a recipe, which then ensures that the package fits into the local package database.

Maintenance of configuration

Updating configuration files can be particularly problematic. Because package managers, at least on Unix systems, originated as extensions of file archivers, they can usually only overwrite or preserve configuration files rather than apply rules to them. There are exceptions, which usually concern kernel configuration (which, if corrupted, would leave the computer unusable after a reboot). Problems can arise if the configuration file format changes — for example, if the old file does not explicitly disable new options that should be disabled. Some package managers, such as dpkg on Debian, allow options to be configured during installation. In other situations packages are installed with a default configuration that is then overwritten, for example during a headless installation across a large number of machines. This kind of pre-configured installation is also supported by dpkg.

Repositories

To give users greater control over the software they allow to be installed on their systems — and sometimes for legal reasons or for the distributors' convenience — packages are often downloaded from software repositories.

Upgrade suppression

When a user updates a package using package management software, they are usually shown the actions to be performed (typically a list of packages to be updated, and possibly the old and new version numbers) and are given the option either to accept the update for all packages at once or to select individual packages to update. Many package managers can be configured never to update certain packages, or to update them only when critical vulnerabilities or instability are found in the previous version, as determined by the software developer. This process is called upgrade suppression or version pinning. For example, to prevent updates to the OpenOffice program:

  • yum supports upgrade suppression via the syntax exclude=openoffice*
  • pacman uses IgnorePkg= openoffice (to suppress OpenOffice updates in both cases)
  • dpkg and dselect support partial suppression via the hold flag when selecting packages.
  • APT extends the hold flag with a pinning mechanism, and users can also blacklist a package.
  • aptitude uses the hold and forbid flags:
    • hold: prevents a package from being updated or modified during installation/upgrade.
    • forbid: prevents a package from being installed or reinstalled.
  • Portage supports suppression via the package.mask configuration file.

Cascading package removal

Some of the more advanced package management features offer cascading package removal, in which all packages that depend on the target package are removed, along with all packages that only it depends on.

What is Composer

Composer is a dependency manager for the PHP programming language. It helps you pull third-party libraries (packages) into a project, manage their versions and load classes automatically.

Put simply: instead of manually downloading library files and including them via require, Composer does it for you and keeps your dependencies in order.

Why you need Composer

Composer solves several important problems:

  • Installing libraries with a single command
  • Managing dependency versions
  • Automatic class loading (autoload)
  • Handling dependencies of dependencies
  • A standardized project structure

Composer's main files

Once a project is initialized, two main files appear:

1. composer.json

This is the main configuration file. It lists the project's dependencies.

Example:

{
"require": {
"monolog/monolog": "^3.0"
}
}

2. composer.lock

Locks the exact package versions so the project behaves identically on every machine.

Installing Composer

Windows

Download the installer from the official website and run the .exe.

Linux / macOS

php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
php composer-setup.php
php -r "unlink('composer-setup.php');"

Verification:

composer --version

Initializing a project

Create a new project:

composer init

Composer will ask a few questions and create a composer.json file.

Installing packages

Adding a library:

composer require monolog/monolog

Composer will:

  • download the package
  • create the vendor folder
  • update composer.json
  • create composer.lock

Hooking up the autoloader

After installing packages you need to include the autoloader:

require 'vendor/autoload.php';

Now you can use the library classes:

use Monolog\Logger;
use Monolog\Handler\StreamHandler;

$log = new Logger('name');
$log->pushHandler(new StreamHandler('app.log'));
$log->info('Hello Composer');

Main Composer commands

Command Description
composer install Install dependencies from composer.lock
composer update Update dependencies
composer require Add a package
composer remove Remove a package
composer dump-autoload Regenerate the autoloader
composer show Show installed packages

Dependency versions

Composer uses special symbols to control versions:

"^1.2" → >=1.2 <2.0
"~1.2" → >=1.2 <1.3
"1.2.*" → all 1.2 versions

Example:

{
"require": {
"guzzlehttp/guzzle": "^7.0"
}
}

Class autoloading (PSR-4)

You can set up autoloading for your own classes:

{
"autoload": {
"psr-4": {
"App\\": "src/"
}
}
}

Then run:

composer dump-autoload

Now classes from src/ will be loaded automatically.

Project structure with Composer

project/
│
├── composer.json
├── composer.lock
├── vendor/
│ └── ...
├── src/
│ └── ...
└── index.php

When to use composer install and update

composer install

  • when cloning a project
  • installs the versions from composer.lock

composer update

  • updates dependencies
  • modifies composer.lock

A practical example

Let's create a project and add a library:

composer init
composer require symfony/var-dumper

Usage:

require 'vendor/autoload.php';
dump("Hello Composer");

Advantages of Composer

  • speeds up development
  • a huge package base
  • convenient dependency management
  • the de facto standard for PHP

Summary

Composer is an essential tool for modern PHP development. It automates including libraries, simplifies project structure and makes code more maintainable.

What is npm

npm is the package manager for the Node.js runtime. It lets you install, update and manage the libraries (packages) used in JavaScript and TypeScript projects.

Put simply, npm is:

  • a huge catalogue of ready-made libraries
  • a tool for installing dependencies
  • a package version management system
  • a way to automate development tasks

Why you need npm

Without npm a developer would have to:

  • download libraries by hand
  • keep track of dependencies
  • update everything themselves

npm automates these tasks:

  • installs dependencies with a single command
  • locks package versions
  • lets you share your own libraries

Installing npm

npm is installed automatically together with Node.js.

Check the installation:

node -v
npm -v

Initializing a project

Before using npm you create a configuration file:

npm init

Or automatically:

npm init -y

This creates package.json — the project's main file.

Example:

{
"name": "my-project",
"version": "1.0.0",
"description": "Training project",
"main": "index.js",
"scripts": {
"start": "node index.js"
}
}

Installing packages

Install a package:

npm install lodash

Install as a development dependency:

npm install eslint --save-dev

After installation you get:

  • the node_modules folder
  • the package-lock.json file

Types of dependencies

package.json contains:

"dependencies": {
"lodash": "^4.17.21"
},
"devDependencies": {
"eslint": "^8.0.0"
}
  • dependencies — needed for the application to run
  • devDependencies — needed only during development

Main npm commands

Install the project's dependencies:

npm install

Remove a package:

npm uninstall lodash

Update a package:

npm update

List installed packages:

npm list

npm scripts

You can define commands in package.json:

"scripts": {
"start": "node index.js",
"dev": "nodemon index.js",
"build": "webpack"
}

Running them:

npm run dev

Global installation

Sometimes packages are installed globally:

npm install -g nodemon

Global packages are used as CLI utilities.

Project structure with npm

my-project/
│
├── node_modules/
├── package.json
├── package-lock.json
└── index.js

Advantages of npm

  • A huge number of libraries
  • Simple dependency management
  • Version support
  • Automation scripts
  • Fast installation

Disadvantages of npm

  • Large node_modules size
  • Possible dependency conflicts
  • Sometimes slow installation

npm vs other package managers

  • Yarn — faster installation
  • pnpm — saves disk space
  • npm — the default standard

Summary

npm is the primary tool for JavaScript development. It:

  • manages dependencies
  • automates tasks
  • simplifies development

Without npm, modern Node.js development is virtually impossible.

What is pip

pip is the standard package manager for the Python programming language.
It lets you install, update and remove third-party libraries from the official Python Package Index (PyPI) repository.

Put simply, pip is a tool that helps you quickly add ready-made modules to your project instead of writing everything from scratch.

Why you need pip

With pip you can:

  • install libraries
  • update packages
  • remove unneeded dependencies
  • save the project's dependency list
  • manage library versions

For example, if you need a library for making HTTP requests, a single command is enough.

Checking that pip is installed

pip is usually installed together with Python. You can check with:

pip --version

If it is installed, you will see the version number.

Main pip commands

Installing a package

pip install requests

This installs the requests library from PyPI.

Installing a specific version

pip install requests==2.31.0

Useful when a project requires a particular version.

Updating a package

pip install --upgrade requests

Updates the package to the latest version.

Removing a package

pip uninstall requests

Removes the library from the system.

Listing installed packages

pip list

Shows all installed libraries

The requirements.txt dependency file

Projects usually keep a dependency file:

Creating it:

pip freeze > requirements.txt

Installing from the file:

pip install -r requirements.txt

This matters when working in a team — everyone uses the same library versions.

Virtual environments (recommended)

pip is often used together with virtual environments so that dependencies of different projects do not conflict.

Creating an environment:

python -m venv venv

Activating it (Windows):

venv\Scripts\activate

Once activated, pip installs packages only for this project.

Where pip gets packages from

By default pip uses the repository:

  • Python Package Index

It hosts tens of thousands of libraries, from web frameworks to machine learning.

Popular alternatives to pip

Other tools are sometimes used:

  • pipenv — combines pip and virtual environments
  • Poetry — a modern dependency manager
  • conda — popular in scientific computing

But pip remains the most basic and universal option.

A complete workflow example

python -m venv venv
venv\Scripts\activate
pip install flask
pip freeze > requirements.txt

Summary

pip is:

  • the standard package manager for Python
  • easy to use
  • an essential tool for any Python developer
  • the foundation of project dependency management

Without pip, modern Python development is virtually impossible.

What is Maven

Apache Maven is a dependency management and project build tool most often used in Java projects. It automates downloading libraries, compiling code, running tests and producing finished applications.

Maven is not merely a package manager but a full-fledged project build system.

Why you need Maven

Without Maven a developer has to:

  • download libraries manually
  • keep track of versions
  • configure the classpath
  • write build scripts

Maven does this automatically:

  • downloads dependencies
  • updates versions
  • manages the project structure
  • runs the build
  • runs the tests

Key Maven features

  • Dependency management
  • A standardized project structure
  • Automatic builds
  • Plugin support
  • Creating JAR/WAR files
  • Version management

Maven project structure

A typical project structure:

project
├── src
│ ├── main
│ │ ├── java
│ │ └── resources
│ └── test
│ └── java
└── pom.xml

The main file is pom.xml

The pom.xml file

This is Maven's configuration file. It describes:

  • project information
  • dependencies
  • plugins
  • build settings

An example of a minimal pom.xml:

 Package Managers: Composer, npm, pip, Maven, apt and Homebrew

Adding a dependency

For example, let's add the JUnit library:

 Package Managers: Composer, npm, pip, Maven, apt and Homebrew

After that Maven will download the library itself.

Main Maven commands

Command What it does
mvn compile compiles the project
mvn test runs the tests
mvn package builds a JAR/WAR
mvn install installs into the local repository
mvn clean cleans the build

Example:

mvn clean package

The Maven lifecycle

Maven uses a lifecycle (build lifecycle):

  1. validate
  2. compile
  3. test
  4. package
  5. verify
  6. install
  7. deploy

Each phase runs automatically when a later one is invoked.

Maven repositories

Maven downloads dependencies from:

  • the local repository (~/.m2)
  • the central repository Maven Central
  • corporate repositories (for example Nexus Repository Manager, JFrog Artifactory)

Maven plugins

Plugins extend Maven's functionality:

Example:

 Package Managers: Composer, npm, pip, Maven, apt and Homebrew

Advantages of Maven

  • automatic dependency management
  • a single standard for projects
  • a large number of plugins
  • convenient for CI/CD
  • IDE support

Disadvantages of Maven

  • verbose XML configuration
  • slower than Gradle
  • hard to customize

Maven vs other managers

  • Maven — declarative (XML)
  • Gradle — script-based (Groovy/Kotlin)
  • Apache Ant — manual builds

When to use Maven

Maven is a good fit if:

  • the project is written in Java
  • you need a standard structure
  • stability matters
  • CI/CD is in use

Summary

Maven is a powerful dependency manager and build system that:

  • automates development
  • simplifies library management
  • standardizes projects

The APT package manager — a tutorial article

APT (Advanced Package Tool) is the package management system used in Debian-based Linux operating systems, such as Ubuntu, Linux Mint and others. It lets you install, update and remove programs from repositories automatically.

What APT is

APT is a layer on top of the low-level package manager dpkg.
APT makes the work easier by automatically:

  • finding dependencies
  • downloading packages from repositories
  • installing them in the correct order
  • updating the system

Key APT capabilities

APT lets you:

  • install programs
  • remove programs
  • search for packages
  • update the system
  • clear the package cache

Main APT commands

Updating the package list

sudo apt update

This command refreshes the list of available packages from the repositories.

Updating installed programs

sudo apt upgrade

Updates all installed packages to newer versions.

A full system upgrade:

sudo apt full-upgrade

Installing a package

sudo apt install package_name

Example:

sudo apt install git

Removing a package

Remove a program:

sudo apt remove package_name

Remove it along with its configuration:

sudo apt purge package_name

Searching for a package

apt search name

Example:

apt search nginx

Package information

apt show package_name

Clearing the cache

APT keeps the packages it downloads. To clear the cache:

sudo apt clean

Remove unneeded dependencies:

sudo apt autoremove

APT repositories

APT downloads packages from repositories — dedicated servers hosting software.

The file listing the repositories:

/etc/apt/sources.list

After changing the repositories you need to run:

sudo apt update

The difference between apt and apt-get

The commands used previously were:

  • apt-get
  • apt-cache

The modern apt command combines their functions and is more user-friendly.

Example:

apt-get install → apt install
apt-get update → apt update

A complete workflow example

sudo apt update
sudo apt upgrade
sudo apt install curl
sudo apt autoremove

Advantages of APT

automatic dependency installation
huge official repositories
simple commands
safe updates
convenient for administration

Disadvantages

works only on Debian-based systems
requires administrator privileges

Summary

APT is one of the most convenient package managers in Linux. It lets you install programs quickly, keep the system up to date and automate administration.

The Homebrew package manager

Homebrew is a popular package manager for the macOS and Linux operating systems. It makes it easy to install, update and remove programs from the command line.

1. What Homebrew is

Homebrew is a tool that automates installing software from source code or from prebuilt packages. Instead of downloading applications manually, you type a single command and everything is installed automatically.

Key capabilities:

  • installing programs
  • updating packages
  • removing programs
  • managing dependencies
  • searching for packages

2. Installing Homebrew

Run this command in the terminal:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

After installation, verify it:

brew --version

If the version is displayed, the installation succeeded

3. Main Homebrew commands

Searching for a package

brew search wget

Installing a package

brew install wget

Updating the package list

brew update

Updating installed programs

brew upgrade

Removing a package

brew uninstall wget

Listing installed packages

brew list

4. Formulae and Casks

Homebrew has two kinds of packages:

1. Formulae

Used for CLI utilities:

brew install git

2. Casks (graphical applications)

Used for GUI programs:

brew install --cask google-chrome

5. Dependency management

Homebrew installs dependencies automatically.
For example:

brew install node

It will automatically install everything needed for it to work.

6. Updating Homebrew and cleaning up

Update Homebrew:

brew update

Remove old versions:

brew cleanup

Check the system:

brew doctor

7. Advantages of Homebrew

Easy to use
Fast software installation
Automatic dependencies
A large number of packages
Open source

8. A complete workflow example

brew update
brew install git
brew install node
brew install --cask visual-studio-code
brew upgrade
brew cleanup

9. When Homebrew is used

Homebrew is commonly used by:

  • developers
  • system administrators
  • DevOps engineers
  • students learning to program

10. Summary

Homebrew is a powerful and convenient package manager that greatly simplifies working with software on macOS and Linux. It lets you manage software with a few simple commands and saves a great deal of time.

Similar programs and platforms

Installers

A package manager is often called an installation manager, which can lead to confusion between package managers and installers. The differences are as follows:

Criterion Package manager Installer
Shipped with Usually the operating system Each individual computer program
Location of installation information A single central installation database Entirely up to the installer. It may be a file in the application folder or among the operating system's files and folders. At best it may register itself in the list of uninstallers without exposing the installation information.
Scope of maintenance Potentially every package on the system. Only the product it was bundled with.
Developed by A single package manager vendor Multiple installer vendors
Packaging format Several well-known formats There can be as many formats as there are applications.
packaging format compatibility It can be used as long as the package manager supports it. Either new versions of the package manager keep supporting it, or the user does not upgrade the package manager. An installer is always compatible with its own archive format, if it uses one. However, installers, like all computer programs, can be subject to software obsolescence.
This box:
  • view
  • talk
  • edit

Build automation utilities

Most software configuration management systems treat building and deploying software as separate, independent stages. A build automation utility typically takes human-readable source files already present on the machine and automates the process of turning them into an executable package on the same or a remote machine. A package manager, usually running on a different machine, then downloads the prebuilt executable and installs it.

Both kinds of tools, however, have much in common:

  • The topological sort of the dependency graph used by a package manager to handle dependencies between binary components is also used by a build manager to handle dependencies between source components.
  • Many makefiles support not only building executables but also installing them via the ` make install command.
  • Every package manager for source-based distributions — such as Portage, Sorcery or Homebrew — supports turning source code into executable binaries and installing them.

Some tools, such as Maak and AAP, are designed to handle both building and deployment and can be used as build automation utilities, package managers, or both.

app stores

App stores can also be viewed as application-level package managers (without the ability to install software at every level). Unlike traditional package managers, app stores are designed around paying for the software itself (rather than around software development) and may offer only monolithic packages with no dependencies or dependency resolution. They are usually limited in management functionality because they favour ease of use over power or evolution, and they are common on commercial operating systems and smart devices.

Package managers also often carry only human-reviewed code. Many app stores, such as Google Play and Apple's App Store, vet applications mainly with automated tools; malware can pass these tests by detecting when an app is being tested and delaying its malicious activity. There are exceptions: the npm package database, for instance, relies entirely on post-publication code review, whereas the Debian package database has an extensive human review process before any package reaches the main database. The XZ Utils backdoor used years of trust-building to plant a backdoor that was nevertheless discovered in the testing database.

Common package managers and formats

Universal package manager

Also known as a binary repository manager, this is a software tool designed to optimize the downloading and storage of binaries, artifacts and packages used and produced during software development. These package managers aim to standardize an enterprise's approach to all types of packages. They give users the ability to apply security and compliance metrics to every type of artifact. Universal package managers have been called the central element of the DevOps toolchain.

Package formats

Main articles: Package format and File archive

Every package manager relies on the format and metadata of the packages in its repository. That is, package managers need groups of files to build together with the corresponding metadata, such as dependencies. Often a base set of utilities handles the core installation from these packages, and several package managers use those utilities to provide additional functionality.

For example, yum uses rpm as its backend. Yum extends rpm's functionality by adding capabilities such as easy configuration for maintaining a network of systems. As another example, Synaptic Package Manager provides a graphical user interface using the Advanced Packaging Tool (apt) library, which in turn uses dpkg to provide the core functionality.

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

For mobile operating systems, Google Play uses the Android application package (APK) format, while the Microsoft Store uses the APPX and XAP formats. Both Google Play and the Microsoft Store have their own package managers.

Free and open source software systems

Because of the nature of free and open source software (FOSS), packages under similar and compatible licenses are available for a range of operating systems. These packages can be combined and distributed using configurable package management systems, which makes it possible to handle many software variants and to manage version-specific dependencies and conflicts. Some FOSS package managers are themselves released as FOSS. One typical difference between package management systems on proprietary operating systems such as Mac OS X and Windows and those in free and open source software such as Linux is that FOSS systems allow third-party packages to be installed and updated through the same mechanism, whereas the Mac OS X and Windows package managers only update software supplied by Apple and Microsoft respectively (with the exception of some third-party drivers on Windows). The ability to continuously update third-party software is usually added by adding the URL of the corresponding repository to the package management system's configuration file.

Application-level package managers

See also: List of software package management systems § Application-level package managers

In addition to system-level application managers, there are additional package managers for operating systems with limited capabilities, as well as for programming languages whose developers need the very latest libraries.

Unlike system package managers, application-level package managers focus on a small part of the software system. They typically live in a directory tree that is not maintained by the system manager, for example c:\cygwin or /opt/sw. This may not hold for managers dealing with programming libraries, which can lead to conflicts, since both managers may claim ownership of a file and may break updates.

Impact

Ian Murdock remarked that package management is «the single biggest advancement Linux has brought to the industry», that it blurs the boundaries between operating systems and applications, and that it makes it easier to «push new innovations [...] into the marketplace and [...] evolve the OS».

There is also a conference for package manager developers known as PackagingCon. It was founded in 2021 with the goal of exploring different approaches to package management

See also

  • application lifecycle manager
  • List of software package management systems
  • manifest file
  • Packaging format

Comments

To leave a comment

If you have any suggestion, idea, thanks or comment, feel free to write. We really value feedback and are glad to hear your opinion.
To reply

Lectures and tutorial on "Software and information systems development"

Terms: Software and information systems development