Skip to main content
Engineering LibreTexts

11-A.1: Who are the Package Managers

  • Page ID
    40985
  • \( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \) \( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)\(\newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\) \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\) \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\) \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\) \( \newcommand{\Span}{\mathrm{span}}\) \(\newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\) \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\) \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\) \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\) \( \newcommand{\Span}{\mathrm{span}}\)\(\newcommand{\AA}{\unicode[.8,0]{x212B}}\)

    EXAM OBJECTIVES COVERED
    2.1 Given a scenario, conduct software installations, configurations, updates, and removals.

    Objectives of this Module

    In this lesson, you will:

    • Learn to identify the most common package managers in Linux, including RPM and dpkg.
    • Practice managing RPM packages with the YUM front-end.
    • Practice managing Debian packages with the APT front-end.
    • Learn how to acquire software through methods other than the usual Linux package managers.
    • Learn how to compile software packages from source code.

    Package Manager

    Every computerized device uses some form of software to perform its intended tasks. In the early days of software, products were stringently tested for bugs and other defects. For the last decade or so, software has been released via the internet with the intent that any bugs would be fixed by applying new versions of the software. In some cases, each individual application has its own updater. In others, it is left up to the user to figure out how to obtain and upgrade software.

    This video give a brief overview of package management in Linux. This is by no means an exhaustive tutorial, as various Linux distributions use different package managers.

    How was software on Linux installed before package managers?

    Historically, software was provided either via FTP or mailing lists (eventually this distribution would grow to include basic websites). Only a few small files contained the instructions to create a binary (normally in a tarfile). You would untar the files, read the readme, and as long as you had GCC or some other form of C compiler, you would then typically run a ./configure script with some list of attributes, such as pathing to library files, location to create new binaries, etc. In addition, the configure process would check your system for application dependencies. If any major requirements were missing, the configure script would exit and you could not proceed with the installation until all the dependencies were met. If the configure script completed successfully, a Makefile would be created.

    Once a Makefile existed, you would then proceed to run the make command (this command is provided by whichever compiler you were using). The make command has a number of options called make flags, which help optimize the resulting binaries for your system. In the earlier days of computing, this was very important because hardware struggled to keep up with modern software demands. Today, compilation options can be much more generic as most hardware is more than adequate for modern software.

    Finally, after the make process had been completed, you would need to run make install (or sudo make install) in order to actually install the software. As you can imagine, doing this for every single piece of software was time-consuming and tedious—not to mention the fact that updating software was a complicated and potentially very involved process.

    What is a Package?

    Packages were invented to combat this complexity. Packages collect multiple data files together into a single archive file for easier portability and storage, or simply compress files to reduce storage space. The binaries included in a package are pre-compiled with default compiler options chosen by the developer. If you so desire, you can compile the source files yourself and choose different compiler options.. Packages also contain metadata, such as the software's name, a description of its purpose, a version number, and a list of dependencies necessary for the software to run properly.

    Several flavors of Linux have created their own package formats. Some of the most commonly used package formats include:

    • .deb: This package format is used by Debian, Ubuntu, Linux Mint, and several other derivatives. It was the first package type to be created.
    • .rpm: This package format was originally called Red Hat Package Manager. It is used by Red Hat, Fedora, SUSE, and several other smaller distributions.
    • .tar.xz: While it is just a compressed tarball, this is the format that Arch Linux uses.

    While packages themselves don't manage dependencies directly, they represented a huge step forward in Linux software management.

    What is a Software Repository?

    A few years ago, before the proliferation of smartphones, the idea of a software repository was difficult for many users to grasp if they were not involved in the Linux ecosystem. To this day, most Windows users still seem to be hardwired to open a web browser to search for and install new software. However, those with smartphones have gotten used to the idea of a software "store." The way smartphone users obtain software and the way package managers work are not dissimilar. While there have been several attempts at making an attractive UI for software repositories, the vast majority of Linux users still use the command line to install packages. Software repositories are a centralized listing of all of the available software for any repository the system has been configured to use.

    Installing Software from Source Code in Linux

    One of the greatest strengths of your Linux distribution is its package manager and the associated software repository. With them, you have all the necessary tools and resources to download and install new software on your computer in a completely automated manner.

    But despite all their efforts, the package maintainers cannot handle each and every use case. Nor can they package all the software available out there. So there are still situations where you will have to compile and install new software by yourself. One of the most common reasons to compile software is when there is a need to run a very specific version, or modify the source code by the use of some fancy compilation option.

    Understanding the Build System of the Program

    We usually talk about “compiling the sources,” but the compilation is only one of the phases required to produce a working software from its source. A build system is a set of tool and practices used to automate and articulate those different tasks in order to entirely build the software just by issuing few commands.

    If the concept is simple, the reality is somewhat more complicated, because different projects or programming languages may have different requirements. There is an almost endless list of reasons to choose or create another build system. All that to say there are many different solutions used out there.

    Red Hat Linux - using RPM Debian Linux - iusing dpkg
    • RedHat Enterprise Linux
    • Fedora
    • CentOS
    • Oracle Enterprise Linux
    • Scientific
    • CERN
    • SUSE
    • OpenSUSE
    • Mageia
    • PCLinuxOS
    • Berry
    • Elastix
    • ClearOS
    • FrameOS
    • Fermi
    • Turbolinux
    • Debian
    • Ubuntu
    • Kali
    • Lubuntu
    • Xubuntu
    • Kubuntu
    • Linux Mint
    • Knoppix
    • Deepin
    • peppermint
    • bodhi linux

    RPM-based Package Managers

    Updating RPM-based systems, particularly those based on Red Hat technologies, has a very interesting and detailed history. In fact, the current versions of yum (for enterprise distributions) and DNF (for community) combine several open source projects to provide their current functionality.

    Initially, Red Hat used a package manager called RPM (Red Hat Package Manager), which is still in use today. However, its primary use is to install RPMs, which you have locally, not to search software repositories. The package manager named up2date was created to inform users of updates to packages and enable them to search remote repositories and easily install dependencies. While it served its purpose, some community members felt that up2date had some significant shortcomings.

    The current incantation of yum came from several different community efforts. Yellowdog Updater (YUP) was developed in 1999-2001 by folks at Terra Soft Solutions as a back-end engine for a graphical installer of Yellow Dog Linux. Duke University liked the idea of YUP and decided to improve upon it. They created Yellowdog Updater, Modified (yum) which was eventually adapted to help manage the university's Red Hat Linux systems. Yum grew in popularity, and by 2005 it was estimated to be used by more than half of the Linux market. Today, almost every distribution of Linux that uses RPMs uses yum for package management (with a few notable exceptions).

    Debian-based Package Managers

    One of the oldest Linux distributions currently maintained, Debian's system is very similar to RPM-based systems. They use .deb packages, which can be managed by a tool called dpkg. dpkg is very similar to RPM in that it was designed to manage packages that are available locally. It does no dependency resolution (although it does dependency checking), and has no reliable way to interact with remote repositories. In order to improve the user experience and ease of use, the Debian project commissioned a project called Deity. This codename was eventually abandoned and changed to Advanced Package Tool (APT).

    Released as test builds in 1998 (before making an appearance in Debian 2.1 in 1999), many users consider APT one of the defining features of Debian-based systems. It makes use of repositories in a similar fashion to RPM-based systems, but instead of individual .repo files that yum uses, APT has historically used /etc/apt/sources.list to manage repositories. More recently, it also ingests files from /etc/apt/sources.d/. Following the examples in the RPM-based package managers, to accomplish the same thing on Debian-based distributions you have a few options. You can edit/create the files manually in the aforementioned locations from the terminal, or in some cases, you can use a UI front end (such as Software & Updates provided by Ubuntu et al.).

    Dandified Yum (DNF)

    DNF is a newer iteration on yum. Introduced in Fedora 18, it has not yet been adopted in the enterprise distributions, and as such is predominantly used in Fedora (and derivatives). Its usage is almost exactly the same as that of yum, but it was built to address poor performance, undocumented APIs, slow/broken dependency resolution, and occasional high memory usage. DNF is meant as a drop-in replacement for yum, and therefore I won't repeat the commands—wherever you would useyum, simply substitutednf.

    Zypper

    Zypper is another package manager meant to help manage RPMs. This package manager is most commonly associated with SUSE (and openSUSE) but has also seen adoption by MeeGo, Sailfish OS, and Tizen. It was originally introduced in 2006 and has been iterated upon ever since. There is not a whole lot to say other than Zypper is used as the back end for the system administration tool YaST and some users find it to be faster than yum.

    Zypper's usage is very similar to that of yum. To search for, update, install or remove a package, simply use the following:

    zypper search kate
    zypper update
    zypper install kate
    zypper remove kate
    

    Some major differences come into play in how repositories are added to the system with zypper. Unlike the package managers discussed above, zypper adds repositories using the package manager itself.

    Adapted from:
    "The evolution of package managers" by Steve Ovens, OpenSource.com is licensed under CC BY-SA 4.0


    This page titled 11-A.1: Who are the Package Managers is shared under a CC BY-SA 4.0 license and was authored, remixed, and/or curated by Patrick McClanahan.

    • Was this article helpful?