Package managers give Linux a reliable way to install, update, and remove software. Instead of downloading random installers, you use repositories that track dependencies and supported versions.
For DevOps teams, that predictability matters. It helps with server provisioning, patching, image builds, and keeping systems consistent across environments.
On Ubuntu and Debian based systems, apt is the standard package tool.
sudo apt updateThis updates the local package index so the system knows what versions are available.
sudo apt install nginx
sudo apt install git curlAPT automatically resolves dependencies, which is one reason package management is easier than manual installs.
sudo apt remove nginx
sudo apt autoremoveapt remove uninstalls the chosen package. apt autoremove cleans up dependency packages that are no longer needed.
apt list --installed
apt list --upgradable
apt list nginxThese commands help you check what is installed, what can be upgraded, and whether a package exists.
Tip: A safe APT habit is
apt updatefirst, then inspect or install. Old package metadata often causes confusion.
Red Hat style distributions commonly use dnf. Older guides may say yum, but the workflow is very similar.
sudo dnf install nginx
sudo dnf install git curl
sudo dnf updatesudo dnf remove nginx
dnf list installed
dnf list available
dnf list nginxThe pattern is the same as APT: install trusted packages, update carefully, and remove software you do not need.
Note: Package names are not always identical across distributions. A package on Ubuntu may use a different name on Fedora or RHEL.
Traditional distro packages are not the only way to distribute Linux software.
Snap packages bundle applications in a more self-contained format.
sudo snap install code --classic
snap list
sudo snap remove codeSnaps are convenient across distributions, but they may use more disk space or start more slowly because more dependencies are bundled.
An AppImage is usually one executable file that you download and run directly.
chmod +x MyTool.AppImage
./MyTool.AppImageThis is simple, but updates and lifecycle management are less centralized than with APT or DNF.
Sometimes you do not want the latest version immediately. Production systems may depend on a known-good release, or you may want to delay an upgrade until testing is complete.
sudo apt-mark hold nginx
sudo apt-mark unhold nginxA held package is skipped during normal upgrades.
APT can also use preference files under /etc/apt/preferences.d/ for stronger pinning rules when administrators need to prefer a specific version or repository.
On RHEL style systems, administrators often manage versions through repository policy, explicit version installs, or the versionlock plugin when it is available.
sudo dnf install nginx-1.24.0
sudo dnf versionlock add nginxExact version locking support depends on the distribution and plugins installed, so it is worth checking your environment.
Imagine you are preparing a VM for a web service. On Ubuntu you might do:
sudo apt update
sudo apt install nginx curl git
apt list --installed | grep nginxOn Fedora or RHEL you might do:
sudo dnf install nginx curl git
sudo dnf updateThe details differ, but the logic stays the same:
APT and DNF solve the same problem on different Linux families: managing software packages and dependencies. Snap and AppImage provide alternative distribution models, but repository-based package management remains central on most servers.
As you move into automation and operations, package management becomes part of repeatable infrastructure rather than one-off software installation.
<MCQExercise
exercise={{
id: "linux-package-management-q1",
title: "Exercise 1: Refreshing package metadata",
description: "Which APT command refreshes the local package index without upgrading installed packages?",
options: [
{ id: "a", text: "sudo apt update" },
{ id: "b", text: "sudo apt autoremove" },
{ id: "c", text: "sudo apt remove" },
{ id: "d", text: "apt list --installed" },
],
correctId: "a",
explanation: "apt update downloads current repository metadata so the system knows what package versions are available. It does not upgrade installed packages by itself.",
wrongExplanations: {
b: "apt autoremove cleans up unused dependency packages. It does not refresh repository metadata.",
c: "apt remove uninstalls a package. It is not related to updating the package index.",
d: "apt list --installed only shows package information. It does not contact repositories.",
},
}}
/>
<MCQExercise
exercise={{
id: "linux-package-management-q2",
title: "Exercise 2: Removing leftover dependencies",
description: "After uninstalling a package on Ubuntu, which command is commonly used to remove dependencies that are no longer needed?",
options: [
{ id: "a", text: "sudo apt install" },
{ id: "b", text: "sudo apt autoremove" },
{ id: "c", text: "sudo dnf list" },
{ id: "d", text: "snap list" },
],
correctId: "b",
explanation: "apt autoremove removes packages that were installed as dependencies but are no longer required. It helps keep systems cleaner after software removal.",
wrongExplanations: {
a: "apt install adds software rather than cleaning up unused dependencies.",
c: "dnf list belongs to Red Hat style systems and only displays package information.",
d: "snap list shows installed snaps and has nothing to do with APT dependency cleanup.",
},
}}
/>
<MCQExercise exercise={{ id: "linux-package-management-q3", title: "Exercise 3: Understanding AppImage", description: "What best describes an AppImage in Linux?", options: [ { id: "a", text: "A repository mirror that replaces APT and DNF" }, { id: "b", text: "A system service that starts software at boot" }, { id: "c", text: "A single executable application file that you usually make executable and run directly" }, { id: "d", text: "A firewall rule format used by Ubuntu" }, ], correctId: "c", explanation: "An AppImage is typically one downloadable file that you mark executable and launch directly. It is simple to use, but updates and central management are less integrated than distro package managers.", wrongExplanations: { a: "An AppImage is not a repository system and does not replace APT or DNF.", b: "That describes service management, not application packaging.", d: "Firewall rules are unrelated to AppImage packaging.", }, }} />
remove uninstalls the package but leaves its configuration files in place, so reinstalling restores your settings. purge removes the configuration too, which is what you want when a broken config is the reason you are reinstalling. autoremove deletes packages that were pulled in as dependencies and are no longer needed by anything. Worth running occasionally, and worth reading the list first, because it occasionally proposes removing something you installed indirectly but do want.
Usually a stale package index. apt-get update refreshes the metadata, and install then finds the package. This is exactly why update and install must share a single RUN in a Dockerfile, or the cached index goes stale. If it still fails after updating, the package is genuinely not in your configured repositories: check the spelling with apt-cache search <name>, and check whether it needs a PPA, a third-party repository or a different name on your distribution.
Another process holds the package manager lock, usually an automatic update running in the background, or a previous command that was interrupted. Wait a minute and retry, since unattended-upgrades finishes on its own. If nothing is running, sudo lsof /var/lib/dpkg/lock-frontend names the holder. Deleting the lock file is the advice you will find online and is a last resort: do it only after confirming no apt or dpkg process exists, then run sudo dpkg --configure -a to repair any half-finished state.
rpm is the low-level package format and tool: it installs a single .rpm file and will not resolve dependencies for you. yum was the dependency-resolving package manager built on top of it, and dnf is its rewritten successor, on current RHEL, CentOS Stream and Fedora, yum is a symlink to dnf and the two are interchangeable. Use dnf for anything from a repository, and rpm -qa, rpm -ql and rpm -qf for querying what is installed and which package owns a file.
Distribution packages first: they are smaller, start faster, integrate with the system, and receive security updates through the channel you already monitor. Snap and Flatpak bundle their dependencies, which makes them useful for desktop applications that need newer libraries than your release ships, at the cost of size and slower first launch. On a server, prefer the distribution's packages or containers. Snaps auto-update on their own schedule, which is rarely what you want on infrastructure.
Learn Linux environment variables: shell versus exported variables, .bashrc versus .bash_profile, extending PATH safely and why sudo drops your environment.
Schedule jobs with crontab: the five time fields, common examples, why a script that works manually fails in cron, capturing output, and systemd timers.
Set up SSH keys properly: generate Ed25519 keys with ssh-keygen, fix permission errors that block a valid key, use ssh-agent, ~/.ssh/config and ProxyJump.