Package Management
Chapter 14
When navigating the Linux community, we encounter diverse opinions on the "best" Linux distribution, often delving into trivial debates like desktop aesthetics. Yet, the crux of a distribution's quality lies in its packaging system and the robustness of its support network. Linux's software landscape is ever-evolving, with frequent updates and new versions across top-tier distributions every six months, and continuous program updates daily. Effective package management tools become essential in navigating this dynamic software environment.
Package management, the method for installing and maintaining software, has significantly evolved. Today, most users fulfill their software needs by installing packages from their Linux distributor, a far cry from the early days of downloading and compiling source code for installation. While compiling code isn't obsolete and remains a fascinating aspect of Linux, precompiled packages offer swifter and more user-friendly installation processes.
This chapter delves into command line tools for package management. While major distributions provide sophisticated graphical programs for system maintenance, understanding command line tools is crucial as they tackle tasks that may be challenging or impossible through their graphical counterparts.
Packaging Systems
Various distributions employ distinct packaging systems, typically rendering a package designed for one distribution incompatible with another. Broadly, distributions align with one of two packaging technologies: the Debian .deb system or the Red Hat .rpm system. While exceptions like Gentoo, Slackware, and Foresight exist, the majority adhere to either of these two foundational systems.
Debian Style (.deb)
Debian, Ubuntu, Xandros, Linspire
Red Hat Style (.rpm)
Fedora, CentOS, Red Hat Enterprise Linux, OpenSUSE, Mandriva, PCLinuxOS
How A Package System Works
In the proprietary software domain, the typical software distribution involves purchasing installation media, like an "install disk," and employing an "installation wizard" to add a new application to the system.
Contrarily, Linux follows a different approach. Almost all Linux software is sourced from the Internet. The majority is supplied by the distribution vendor in the shape of package files, while the rest exists in source code form, allowing for manual installation. Installing software by compiling source code will be covered in a subsequent chapter.
Package Files
The fundamental component within a packaging system is the package file—a compressed assembly of files constituting a software package. It can encompass multiple programs and supporting data files. Alongside the installation files, a package file contains metadata detailing the package and its contents. Moreover, many packages feature pre- and post-installation scripts, executing configuration tasks before and after installation.
These package files are crafted by a figure known as a package maintainer, typically associated (though not always) with the distribution vendor. The package maintainer acquires the software in its source code form from the upstream provider (the program's author), compiles it, and generates the package metadata along with any essential installation scripts. Often, modifications are made to the original source code by the package maintainer to enhance the program's compatibility with other components of the Linux distribution.
Repositories
While a few software projects opt for handling their own packaging and distribution, the majority of packages are crafted by distribution vendors and interested third parties. These packages are housed in central repositories curated for each distribution, often containing thousands of packages, each meticulously tailored and maintained.
A distribution typically oversees multiple repositories catering to distinct stages of the software development life cycle. For instance, there's commonly a "testing" repository housing freshly built packages, intended for the intrepid users who scout for bugs prior to their general release. Additionally, a "development" repository harbors work-in-progress packages slated for inclusion in the distribution's forthcoming major release.
Moreover, distributions might feature related third-party repositories. These repositories serve to provide software that, due to legal constraints like patents or DRM anti-circumvention issues, cannot be included within the distribution itself. A well-known instance involves encrypted DVD support, which lacks legality in the United States. These third-party repositories operate in regions exempt from software patents and anti-circumvention laws. They typically remain wholly independent of the distribution they support, necessitating users' manual inclusion of their configuration files within the package management system to access them.
Dependencies
Software programs rarely operate in isolation; they often depend on other software components to accomplish their tasks. Everyday functions like input/output are managed by routines shared among multiple programs. These routines reside in shared libraries, offering crucial services to multiple programs. When a package necessitates a shared resource like a shared library, it's deemed to have a dependency. Contemporary package management systems universally offer some form of dependency resolution to guarantee that upon installing a package, all its dependencies are also installed.
High And Low-level Package Tools
Package management systems typically comprise two categories of tools: low-level tools, managing tasks like installing and removing package files, and high-level tools responsible for metadata searching and dependency resolution. In this chapter, we'll explore the tools offered within Debian-style systems (such as Ubuntu and similar distributions) as well as those utilized in recent Red Hat products. While all Red Hat-style distributions rely on the same low-level program (rpm), they employ different high-level tools. In our discussion, we'll focus on the high-level program yum, utilized by Fedora, Red Hat Enterprise Linux, and CentOS. Other Red Hat-style distributions provide high-level tools possessing similar functionalities.
Debian-Style
dpkg
apt-get, aptitude
Fedora, Red Hat Enterprise Linux, CentOS
rpm
yum
Common Package Management Tasks
Numerous operations are executable using command line package management tools, and we'll delve into the most prevalent ones. It's worth noting that the low-level tools also facilitate the creation of package files, an aspect beyond the scope of this book.
Throughout the following discussion, the term "package_name" denotes the specific name of a package, distinct from "package_file," which refers to the file housing the package.
Finding A Package In A Repository
Utilizing high-level tools for repository metadata search enables locating a package by its name or description.
Debian
apt-get update
apt-cache search search_string
Red Hat
yum search search_string
For instance, to query a yum repository for the emacs text editor, you can employ this command:
Installing A Package From A Repository
High-level tools facilitate the retrieval and installation of a package from a repository, ensuring complete dependency resolution.
Debian
apt-get update
apt-get install package_name
Red Hat
yum install package_name
Example: To install the emacs text editor from an apt repository:
Installing A Package From A Package File
Should a package file be acquired from a non-repository source, it can be installed directly (albeit without dependency resolution) using a low-level tool.
Debian
dpkg --install package_file
Red Hat
rpm -i package_file
For instance, if the package file emacs-22.1-7.fc7-i386.rpm had been obtained from a source outside a repository, it would be installed in the following manner:
Note
Because this method utilizes the low-level rpm program for installation, it doesn't execute dependency resolution. If rpm detects any missing dependencies, it will terminate with an error.
Removing A Package
You have the option to uninstall packages using either the high-level or low-level tools. Below, the high-level tools are presented.
Debian
apt-get remove package_name
Red Hat
yum erase package_name
Example: To uninstall the emacs package from a Debian-style system:
Updating Packages From A Repository
One of the most frequent package management tasks involves keeping the system updated with the latest packages. High-level tools can execute this crucial task in a single step.
Debian
apt-get update; apt-get upgrade
Red Hat
yum update
Example: To apply any available updates to the installed packages on a Debian-style system:
Upgrading A Package From A Package File
Should an updated version of a package be acquired from a source outside a repository, it can be installed, thereby replacing the previous version:
Debian
dpkg --install package_file
Red Hat
rpm -U package_file
Example: Updating an existing installation of emacs to the version contained in the package file emacs-22.1-7.fc7-i386.rpm on a Red Hat system:
Note
Unlike rpm, dpkg lacks a dedicated option for differentiating between upgrading and installing a package.
Listing Installed Packages
These commands can be used to display a list of all the packages installed on the system:
Debian
dpkg --list
Red Hat
rpm -qa
Determining If A Package Is Installed
These low-level tools can be used to display whether a specified package is installed:
Debian
dpkg --status package_name
Red Hat
rpm -q package_name
Example: To determine if the emacs package is installed on a Debian style system:
Displaying Info About An Installed Package
When you're aware of the installed package name, the following commands can be utilized to showcase a description of the package:
Debian
apt-cache show package_name
Red Hat
yum info package_name
Example: To see a description of the emacs package on a Debian-style system:
Finding Which Package Installed A File
To identify the package accountable for the installation of a specific file, you can utilize the following commands:
Debian
dpkg --search file_name
Red Hat
rpm -qf file_name
Example: To see what package installed the /usr/bin/vim file on a Red Hat system:
Summary
In the upcoming chapters, we'll delve into various programs spanning diverse application domains. Although many of these programs are typically part of default installations, we might require additional packages if certain necessary programs aren't already on our system. Thanks to our enhanced grasp and appreciation of package management, installing and managing the necessary programs shouldn't pose any challenges.
The Linux Software Installation Myth
Individuals transitioning from other platforms may occasionally fall prey to the misconception that installing software on Linux is inherently challenging due to the diversity of packaging systems across distributions. While it can pose challenges for proprietary software vendors aiming to distribute binary-only versions of their confidential software, the Linux software ecosystem operates on the principle of open-source code.
When a program developer releases source code, it often gets packaged by a distribution associate and added to their repository. This approach ensures seamless integration into the distribution, offering users the convenience of centralized software access, bypassing the need to scour individual product websites. Device drivers follow a similar process, often becoming part of the Linux kernel rather than separate items in a distribution's repository. In Linux, there's typically no concept of a "driver disk" as the kernel encompasses support for a wide array of devices, often surpassing Windows' range.
However, encountering unsupported devices may occur due to a few reasons:
Newness: If a device is brand new and lacks active Linux development support from hardware vendors, a Linux community member might need time to develop the kernel driver code.
Exotic Nature: Some distributions may overlook certain devices in their kernel builds due to their uncommon nature. Obtaining the driver's source code allows users to compile and install it themselves.
Vendor Constraints: In instances where hardware vendors withhold source code or technical documentation necessary for creating a Linux driver, they are effectively concealing programming interfaces. In such cases, removing the unsupported hardware might be the best course of action to maintain transparency within your system.
Last updated