Package Management (apt and yum)
Linux distributions almost never require you to compile software from source. Instead, they ship a package manager that downloads pre-built binaries plus metadata (version, dependencies, install scripts) from a trusted repository, and installs them consistently across the system. Debian-family distributions (Ubuntu, Debian, Linux Mint) use apt (and the lower-level dpkg), working with .deb packages. Red Hat-family distributions (RHEL, CentOS Stream, Fedora, Rocky Linux, AlmaLinux) use yum or its modern successor dnf, working with .rpm packages. Both families solve the same problem — dependency resolution, versioned upgrades, and clean removal — with different tooling and slightly different philosophies.
Cricket analogy: Like an IPL franchise buying ready-made players via an official auction rather than training raw talent from scratch, apt and yum fetch pre-built binaries with metadata instead of making you compile from source.
apt on Debian/Ubuntu
apt is the modern, user-friendly front-end that wraps apt-get and apt-cache with a simpler, more consistent command set and a nicer progress display. The package index — the list of available packages and their metadata — lives in files under /etc/apt/sources.list and /etc/apt/sources.list.d/, and must be refreshed with apt update before installing anything new, since it doesn't happen automatically. Installing is apt install <package>, removing is apt remove <package> (which leaves configuration files behind) or apt purge <package> (which removes them too), and apt upgrade installs the newest available versions of already-installed packages without removing or adding packages, while apt full-upgrade (or dist-upgrade) is willing to add/remove packages as needed to resolve upgrade dependencies.
Cricket analogy: Before RCB's team runs a new play, the coach must read the updated scouting report; apt update refreshes the sources.list index before apt install fetches a new package, like signing a fresh recruit ahead of the next fixture.
# Refresh the package index (always do this first)
sudo apt update
# Install a package (and any dependencies)
sudo apt install nginx
# Upgrade all installed packages to their latest available versions
sudo apt upgrade
# Remove a package but keep its config files
sudo apt remove nginx
# Remove a package AND its config files
sudo apt purge nginx
# Remove packages that were installed as dependencies and are no longer needed
sudo apt autoremove
# Search for a package by name/description
apt search "reverse proxy"
# Show detailed info about a package (version, dependencies, description)
apt show nginx
# List installed packages matching a pattern
apt list --installed | grep nginx
# Pin a package to prevent it from being auto-upgraded
sudo apt-mark hold nginxyum and dnf on RHEL/CentOS
yum (Yellowdog Updater, Modified) is the traditional package manager on RHEL/CentOS 7 and earlier; dnf (Dandified YUM) is its successor, used by default on RHEL 8+, CentOS Stream, Fedora, Rocky Linux, and AlmaLinux, offering faster dependency resolution and a cleaner plugin architecture. Critically, dnf is command-line compatible with yum — most yum <subcommand> invocations work identically as dnf <subcommand>, and on modern systems yum is frequently just a symlink to dnf. Unlike apt, yum/dnf refreshes its metadata automatically as needed on most operations, so a separate 'update the index' step is less commonly required, though yum makecache / dnf makecache can force it explicitly. Repository definitions live in /etc/yum.repos.d/*.repo files.
Cricket analogy: dnf succeeding yum is like Rohit Sharma succeeding MS Dhoni as captain — command-line compatible, running the same tactics (yum subcommands) but with faster decision-making (dependency resolution); repo files sit in /etc/yum.repos.d/ like a team's official fixture list.
# Install a package (metadata refreshed automatically if stale)
sudo yum install nginx
# or, on RHEL 8+/Fedora/Rocky:
sudo dnf install nginx
# Update all installed packages
sudo yum update
# Remove a package
sudo yum remove nginx
# Search for a package
yum search "reverse proxy"
# Show package details
yum info nginx
# List installed packages
yum list installed | grep nginx
# Clean up packages installed as dependencies that are now orphaned
sudo yum autoremove
# Enable the EPEL repository for extra community packages (RHEL/CentOS)
sudo yum install epel-releaseThe Debian/RPM ecosystems have a rough command mapping: apt install ↔ yum/dnf install, apt remove ↔ yum/dnf remove, apt search ↔ yum/dnf search, apt show ↔ yum/dnf info, and dpkg -l ↔ rpm -qa for listing all installed packages at the lower level. apt's dependency resolver historically favored a simpler, more conservative approach, while dnf's resolver (based on the libsolv SAT solver) can more aggressively resolve complex conflicting version constraints — both are considered reliable on modern releases.
Never mix package managers for the same software (e.g. installing a library via apt and then manually compiling and make install-ing a conflicting version) — this desyncs the package database from what's actually on disk and causes confusing failures on future upgrades. Also avoid running apt upgrade or yum update unattended on production systems without testing, since a major version bump in a dependency (e.g. a new OpenSSL ABI) can break running services; pin critical packages (apt-mark hold, or exclude= in /etc/yum.conf) when stability matters more than having the latest version.
Adding Repositories and Verifying Packages
Beyond the distribution's default repositories, you'll often add third-party ones — for example, Docker's official apt repo or a vendor's yum repo. On Debian/Ubuntu this means adding a .list file under /etc/apt/sources.list.d/ along with the vendor's GPG signing key (imported via apt-key historically, or the newer signed-by mechanism pointing at a keyring file, since apt-key is deprecated). On RHEL/CentOS this means dropping a .repo file into /etc/yum.repos.d/ or running yum-config-manager --add-repo <url>. Both systems cryptographically verify package signatures against trusted keys before installation, which is why importing the correct GPG key is a mandatory step, not an optional one — skipping it (or worse, disabling signature checks) exposes the system to tampered packages.
Cricket analogy: Adding Docker's third-party apt repo is like an IPL team signing an overseas player — you must verify their board's certification (GPG key) before fielding them, since skipping verification risks fielding an ineligible, untrustworthy player.
- apt (Debian/Ubuntu, .deb packages) requires an explicit
apt updateto refresh its package index before installs; yum/dnf (RHEL family, .rpm packages) refreshes metadata automatically in most cases. - Core apt commands: update, install, remove, purge, upgrade, full-upgrade, autoremove, search, show.
- Core yum/dnf commands: install, update, remove, search, info, list installed — dnf is largely command-compatible with yum and is the default on RHEL 8+.
- apt remove keeps config files; apt purge deletes them too — there's no direct yum/dnf equivalent distinction (yum remove deletes both by default).
- Third-party repositories require adding both a repo definition file and the vendor's GPG signing key — never disable signature verification.
- Pin critical packages (apt-mark hold / yum exclude) on production systems to avoid unexpected breaking upgrades.
Practice what you learned
1. Which command must typically be run before `apt install <package>` to ensure apt knows about the latest available package versions?
2. What is the key difference between `apt remove nginx` and `apt purge nginx`?
3. On RHEL 8, CentOS Stream, and Fedora, which package manager is the default, and how does it relate to yum?
4. Why is importing a vendor's GPG signing key a required step when adding a third-party apt or yum repository?
5. What does `apt autoremove` (or `yum autoremove`) do?
Was this page helpful?
You May Also Like
What Is Linux?
An introduction to Linux as a kernel and family of operating systems: its history, the GNU/Linux relationship, and why it dominates servers, cloud, and embedded devices.
The Linux Filesystem Hierarchy
A tour of the standard Linux directory tree defined by the Filesystem Hierarchy Standard (FHS) — what lives under /etc, /var, /usr, /home, and more, and why the layout matters.
Users, Groups, and sudo
Learn how Linux organizes access through users and groups, how to create and manage them, and how sudo grants temporary elevated privileges safely and auditably.
Disk Usage and Management (df, du, mount)
Learn how to inspect filesystem capacity, measure directory sizes, and understand how block devices get attached to the Linux directory tree via mounting.
Related Reading
Related Study Notes in DevOps
Browse all study notesNginx Study Notes
DevOps · 30 topics
DevOpsAnsible Study Notes
DevOps · 30 topics
DevOpsAdvanced Kubernetes Study Notes
Kubernetes · 30 topics
DevOpsAdvanced Bash Scripting Study Notes
Bash · 30 topics
DevOpsApache Kafka Study Notes
Kafka · 30 topics
DevOpsDocker & Kubernetes Study Notes
YAML · 40 topics