Learn Linux - Package Management Across Distros

#Introduction

After episode 10 where we covered administrator access and sudo management — from the dangers of logging in as root, the difference between su - vs sudo, /etc/sudoers configuration with visudo, to granting NOPASSWD for automation — you now have a secure administrative key. In this episode, we'll use that key for the most fundamental thing a Linux admin does: managing software.

One of the first reasons people shy away from Linux is the confusion when trying to install an app: on Windows you just click a .exe, on macOS you drag a .dmg, but on Linux you have to type commands like apt install nginx. In fact, this is precisely Linux's greatest strength. This episode will explain why package managers exist, how the three big distro families — Debian/Ubuntu, RHEL, and Arch — run them, and the universal formats that fill the gaps between them. Let's begin.

#Main Discussion

#Why Does Linux Use Package Managers?

Think of .exe/.dmg as finding a box of spare parts on the roadside: you never know exactly what's inside, where it came from, whether its version matches your system, and there's no record of who took what. Every .exe from the internet carries its own library versions, puts files wherever it wants, and doesn't coordinate with other applications. The result: two apps can bring conflicting library versions, and there's no centralized way to know "what applications are installed on this machine?".

Package managers remove all that guesswork with four key concepts:

1. Centralized repository — software is taken from official, verified distro servers (mirrors), not from just any internet link.
2. Complete metadata — every package carries a name, version, description, dependencies, and checksum. The system knows exactly what will be installed before installing it.
3. Automatic dependencies — apt install nginx automatically pulls in all the libraries Nginx needs. No more "install this library manually first" drama.
4. Centralized management — a single database records all installed packages. Uninstalling an application is truly clean, and updates can be applied to the whole system at once.

This is why the statement "Linux doesn't have .exe" is a misconception: Linux deliberately doesn't have it, because .exe is a chaotic solution. The package manager model is closer to the iOS App Store or Play Store — one trusted source, centralized updates, and the machine knows the status of every application.

#The Debian/Ubuntu Family: APT

APT (Advanced Package Tool) works on top of .deb packages and reads the repository list from /etc/apt/sources.list and /etc/apt/sources.list.d/. There are two commands you must distinguish from the start: apt update refreshes the list of packages available in the repositories (metadata), while apt upgrade updates the installed packages themselves. apt update doesn't install anything; it only refreshes the catalog.

# Refresh the package catalog from repositories
sudo apt update
 
# Upgrade all installed packages
sudo apt upgrade
 
# Install a new package (with its dependencies)
sudo apt install nginx
 
# Remove a package (without config files)
sudo apt remove nginx
 
# Remove dependencies that are no longer used
sudo apt autoremove

To search and inspect packages, APT provides apt search and apt show:

apt search nginx
apt show nginx

apt show is a highly recommended habit before installing: it shows the version, dependencies, size, and especially the description — so you know exactly what will be installed. In production, running apt search first also avoids installing a package with a similar name by mistake (for example nginx-core vs nginx).

#The RHEL Family: DNF

DNF (Dandified YUM) is the successor to yum in the RHEL family — Rocky Linux, AlmaLinux, Fedora. Its philosophy is the same as APT, but with different terminology. There's no dnf update for the catalog; instead, dnf check-update checks for available updates and dnf update or dnf upgrade applies them.

# Check for available updates (without applying)
sudo dnf check-update
 
# Apply all updates
sudo dnf update
 
# Install a package
sudo dnf install nginx
 
# Remove a package
sudo dnf remove nginx
 
# Search for a package
sudo dnf search nginx

One of DNF's standout advantages is the transaction summary: before executing, DNF shows the packages that will be installed, upgraded, and removed, then asks for confirmation. This gives you a chance to read what will change — a very valuable audit habit in production.

#The Arch Family: Pacman

Pacman is Arch Linux's package manager. Its architecture is rolling release: there's no "distro" version that bumps once a year — updates come continuously. Because of this, one mandatory ritual that can't be skipped is pacman -Syu every time you're about to install something. Let's break down its options:

# Refresh + upgrade all packages first
sudo pacman -Syu
 
# Install a package
sudo pacman -S nginx
 
# Remove a package with its unused dependencies
sudo pacman -Rs nginx

#Direct Comparison of the Three Distro Families

To make the pattern above even clearer, here's a comparison of equivalent commands in the three families. Notice how three different package managers actually do exactly the same thing:

sudo apt update            # refresh the catalog
sudo apt upgrade           # upgrade all
sudo apt install nginx     # install a package
sudo apt remove nginx      # remove a package
apt search nginx           # search for a package

sudo dnf check-update      # check for updates
sudo dnf update            # upgrade all
sudo dnf install nginx     # install a package
sudo dnf remove nginx      # remove a package
dnf search nginx           # search for a package

sudo pacman -Sy            # refresh the catalog
sudo pacman -Syu           # upgrade all
sudo pacman -S nginx       # install a package
sudo pacman -Rs nginx      # remove a package + dependencies
pacman -Ss nginx           # search for a package

The same pattern in different languages — this is what lets an admin move between distros quickly: once you understand the concepts (refresh catalog → install → upgrade → remove → search), the commands are just new vocabulary. What distinguishes them is no longer "how to install", but policy: how often to upgrade, how third-party repositories are handled, and how strict validation is before changes are applied.

#Universal Package Formats: Snap, Flatpak, and AppImage

All three families above share a weakness: a package built for Ubuntu can fail on Arch. The solution to this "one binary for all distros" problem was born in three universal formats. They solve the dependency hell problem differently: bundling the application along with all its dependencies into a single sandbox isolated from the system.

# Snap
sudo snap install code --classic
 
# Flatpak (after adding the Flathub repo)
flatpak install flathub org.audacityteam.Audacity
 
# AppImage — download one file, give execute permission, run
chmod +x ./SomeApp.AppImage
./SomeApp.AppImage

#Common Mistakes in Package Management

The most common trap happens precisely between two commands that look similar: apt update and apt upgrade. Most "repository failed to refresh" or "package not found" problems come from forgetting to run apt update after adding a new repository. Remember the flow: add repository → apt update → then apt install. Installing immediately after adding a PPA without apt update will produce the error "Unable to locate package".

On the other hand, sudo apt upgrade on a production machine isn't a trivial decision. You could suddenly get a new kernel version, libraries whose behavior changes, or service configurations being overwritten. In production, the general policy is don't upgrade carelessly: pin specific package versions, test in staging, and schedule upgrades in a maintenance window. apt upgrade isn't apt-get dist-upgrade (which can change dependencies aggressively), but still — changing hundreds of packages on a live machine without tests is the fastest way to create downtime.

The third very common mistake is a broken PPA. PPA (Personal Package Archive) on Ubuntu is a third-party repository that authors sometimes abandon. Its symptom is typical: apt update errors with "404 Not Found" for one specific repo. The solution isn't deleting all PPAs, but disabling the problematic repo:

# Find out which repo failed — the 404 message names its URL
sudo apt update
 
# List installed PPAs
find /etc/apt/sources.list.d/ -name "*.list" -exec cat {} \;
 
# Remove the abandoned PPA
sudo add-apt-repository --remove ppa:some-owner/abandoned-repo

#Conclusion

In this episode 11 we've mapped the entire package management landscape: understanding why Linux chose centralized repositories instead of .exe/.dmg installers, practicing the complete lifecycle of apt, dnf, and pacman, comparing the three in one table of equivalent commands, and getting to know the universal formats snap, flatpak, and AppImage along with their trade-offs. The most important lesson: a package manager isn't just "a way to install apps" — it's a software sovereignty management system that makes a machine auditable, updatable, and reproducible.

Once applications are properly installed, the next question is: how does Linux know where to look for programs? The answer is in environment variables, especially PATH. In the next episode 12 we'll discuss shell and environment variables — from VAR=x vs export VAR, important variables like HOME, LANG, and PS1, to customizing .bashrc with aliases and functions, plus your first bash script. See you there!