Linux Commands

Introduction to Package Management in Linux

All the operating systems depend on a set of software applications to carry out user intended tasks. In the early days, applications were tested against bugs before release to provide a better user experience. Now the software application is released with the intent to apply bug fixes in new versions. Moreover, each application has its updater, or the user has had to figure out how to obtain the upgraded software release.

Linux adopted the timely software management practice by creating packaging formats, software packages, and unique installation tools. This article discusses how the software package installation process upgraded from tarball package installation to DEB and RPM package management.

Tarball

Earlier Linux systems software addition required the user to download the source code, compile it in binary files, and add it to the system. Sometimes the software was made available by some users in a compiled form known as the tarball. A tarball contains multiple files including, executables, configuration files, documentation, and libraries. Such that all the files are compressed into a single file for easy storage and distribution.

After software installation, the files spread across the system in relevant directories. However, the method of creating tarball may seem easy, but the installation process makes some tasks difficult, for instance:

It requires the user to independently/manually track down the dependencies for the installing software such that the dependent software itself has some dependencies.

Since tarball package installation spreads the files, it won’t be easy to locate the package documentation and configuration files even if the user knows the commands.

It’s hard to locate files to uninstall software.

The absence of metadata in tarballs leaves users confused about the version details after installation. That makes it difficult to track bugs and get new versions.

To overcome these problems, software packaging in the Linux distributions evolved into two packaging formats known as DEB and RPM packaging.

DEB Packaging

The Debian and Debian-based Linux distributions use DEB-base software packaging. The .deb files include all relevant files with metadata in a .ar archive format. The metadata contains all the relevant software details involving version, description, dependencies, licenses, etc. Debian distributions offer multiple graphical interfaces and terminal-based tools to manage .deb files. Some of them include:

  • apt: Ubuntu advanced packaging tool that provides an apt-get command to search and manage package installation.
  • aptitude: the command is a package management tool that provides a text-based interface to run inside the terminal. It performs package installation, removal, and upgrade by using arrow keys and highlighting the selected option.
  • Ubuntu Software Centre: It is an intuitive graphical user interface for beginning Linux users searching and installing packages.

Even though Ubuntu Software Center is intuitive, the advanced packaging management system outperforms all the other PMS for DEB packaging.

RPM Packaging

The RPM (.rpm) packaging format is the preference of SUSE, Fedora, and Red Hat, and RHEL-based Linux distributions. The RPM package is the amalgam of files to provide a photo viewer, word processor, or other software to RHEL distribution users. It also contains configuration files, metadata, and other required documents to create the software.

The RPM Package Manager combines binaries and all the required files available via upstream software providers into an RPM package. Before including packages into the repository, they are signed so the users can verify their validity. Now the user can access these packages for installation from repositories placed inside CDs or directories via NFS or FTP servers.

The RPM package name tells a lot about the software. For instance, type the following command to find out the details of the currently installed RPM package of firefox:

[fedora@fedora]$ rpm -q firefox
firefox-87.0-12.fc34.x86_64
  • 87.0: represents a release number assigned by Mozilla Project
  • 12: represents the number of times Red Hat rebuilds the package at the same release number.
  • fc34.x86_64: represents that the package is built and compiled for the Fedora Linux and x86 64-bit architecture.

To find further details of the package, query the RPM local database by using the rpm command with the -qi option:

[fedora@fedora]$ rpm -qi firefox
Name        : firefox
Version     : 87.0
Release     : 12.fc34
Architecture: x86_64
Install Date: Fri 23 Apr 2021 06:58:19 AM EDT
Group       : Unspecified
Size        : 261285879
License     : MPLv1.1 or GPLv2+ or LGPLv2+
Signature   : RSA/SHA256, Tue 13 Apr 2021 04:59:11 AM EDT, Key ID 1161ae6945719a39
Source RPM  : firefox-87.0-12.fc34.src.rpm
Build Date  : Mon 12 Apr 2021 04:56:26 AM EDT
Build Host  : buildhw-x86-10.iad2.fedoraproject.org
Packager    : Fedora Project
Vendor      : Fedora Project
URL         : https://www.mozilla.org/firefox/
Bug URL     : https://bugz.fedoraproject.org/firefox
Summary     : Mozilla Firefox Web browser
Description :
Mozilla Firefox is an open-source web browser designed for standards
compliance, performance, and portability.

The above output now represents the package built and installation dates, size, firefox package group’s licensing, and many other details. Even though rpm was the first RPM packaging tool command for installation update, query, package removal, etc., it has some fundamental drawbacks.

Dependency Hell: The RPM package installation fails in the absence of dependencies while telling about the required components. Moreover, the dependent package itself has some needed dependencies to get the work done.

RPMs Location: The RPM Package manager expects to receive the package location before installation. If the package is available in the current folder, it requires an input of firefox-87.0-12.fc34.x86_64.rpm, if it’s on the server, it requires http://example.com/firefox-87.0-12.fc34.x86_64.rpm.

Whereas at that time, DEB-based software packaging could automatically resolve the dependencies problem. However, after the increasing popularity of RPM packages, the issues have been resolved with the yum facility.

YUM Project

The Yellowdog Updater Modified (YUM) facility was introduced to manage RPM packages dependencies by considering each RPM package as part of a large software repository. Such that the problem of dealing with the dependencies is for the Linux distribution or third-party software.

It resolves the problems with the concept that repositories can build on each other. For instance, if a user installs some package from the rpmfusion.org repository, which requires a command/tool from the main Fedora repository, it also has access to that. Hence, it will be downloaded and installed in the meantime.

Conclusion

The articles provide a brief history of how the Linux packaging management system has evolved. We discussed .deb and .rpm based software packaging systems for Debian and RHEL based Linux distributions, their most commonly used tools. We also discuss the evolution of the package management systems from the problems faced during the early developmental stages.

About the author

Usama Azad

A security enthusiast who loves Terminal and Open Source. My area of expertise is Python, Linux (Debian), Bash, Penetration testing, and Firewalls. Iā€™m born and raised in Wazirabad, Pakistan and currently doing Undergraduation from National University of Science and Technology (NUST). On Twitter i go by @UsamaAzad14