You typed one command to install a web server and Linux answered with a wall of red text:
$ sudo apt install nginx
Reading package lists... Done
Building dependency tree... Done
E: Could not get lock /var/lib/dpkg/lock-frontend - open (11: Resource temporarily unavailable)
E: Unable to acquire the dpkg frontend lock, is another process using it?Nothing is broken. Another program is already talking to the package system and Linux refuses to let two writers touch it at once. By the end of this part you will know exactly what that lock is, who is holding it, and why deleting it by hand is the wrong move. First, the tool that threw the error.
A package manager installs software and every other piece of software that software needs, tracks what it put where, and takes it all back out cleanly. On Debian and Ubuntu that tool is
apt. On Red Hat, Rocky, AlmaLinux and Fedora it is dnf. Learn the six verbs that do 95 percent of the work, learn where the packages come from, and the rest is detail.Two readers are looking at that error. One just left college and has never installed anything without a graphical store. The other runs forty servers and needs the fast, correct version so the next dependency mess does not eat an afternoon. This part serves both: the plain explanation first, then the real commands with real output.
Here is the map of both tools side by side. Keep it open in a second tab while you follow along; almost every daily task is one row in this table.
| What you want to do | Debian and Ubuntu | RHEL and Fedora |
|---|---|---|
| Refresh the package index | sudo apt update | sudo dnf check-update |
| Install a package | sudo apt install nginx | sudo dnf install nginx |
| Remove a package | sudo apt remove nginx | sudo dnf remove nginx |
| Remove it and wipe its config | sudo apt purge nginx | drops config on remove |
| Upgrade everything installed | sudo apt upgrade | sudo dnf upgrade |
| Search for a package | apt search nginx | dnf search nginx |
| Show details about a package | apt show nginx | dnf info nginx |
| Clean up unused dependencies | sudo apt autoremove | sudo dnf autoremove |
What a package manager actually does for you
Software on Linux almost never arrives as one file. A web server needs an SSL library, that library needs a compression library, and each of those has a version it expects. Download and compile all of that by hand and you own the whole chain forever, including the security patches. A package manager does that bookkeeping. Ask for nginx and it reads the package metadata, works out that nginx needs a handful of other packages, fetches every one, unpacks them in the right order, runs any setup scripts, and writes down exactly which files belong to which package.
That last part is the point people miss. The manager keeps a database of every file it installed. Months later sudo apt remove nginx takes back precisely those files and leaves the rest of the system untouched. Compare that to make install from source, which scatters files across the disk with no record and no clean way out. The package database is the difference between a system you can reason about and one that rots.
Two families, one idea
There are two big package worlds and you will meet both. The Debian world ships .deb packages, and its low level tool is dpkg. On top of dpkg sits apt, which adds the network, the repositories, and dependency solving. The Red Hat world ships .rpm packages with rpm underneath, and dnf on top playing the same role apt plays. Same idea, different file format and different command names.
If you are on Fedora, know that the command is still dnf but the engine changed. Fedora 41 replaced the old Python dnf with dnf5, a faster rewrite that also took over the jobs of yum and microdnf. Your muscle memory is safe; dnf install works exactly as before. On older RHEL 7 systems you will still see yum, which is the ancestor of dnf and takes the same subcommands.
The everyday workflow, start to finish
Refresh, then install
On Debian and Ubuntu you refresh the index first, then install. Here is the full sequence with the output trimmed to what matters:
$ sudo apt update
Hit:1 http://archive.ubuntu.com/ubuntu noble InRelease
Get:2 http://archive.ubuntu.com/ubuntu noble-updates InRelease [126 kB]
Fetched 126 kB in 1s (98.2 kB/s)
Reading package lists... Done
42 packages can be upgraded. Run 'apt list --upgradable' to see them.
$ sudo apt install tree
Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
tree
0 upgraded, 1 newly installed, 0 to remove and 42 not upgraded.
Need to get 47.6 kB of archives.
After this operation, 135 kB of additional disk space will be used.
Get:1 http://archive.ubuntu.com/ubuntu noble/universe amd64 tree amd64 2.1.1-2 [47.6 kB]
Setting up tree (2.1.1-2) ...Read the summary line before you hit yes. It tells you how many packages will be added, upgraded, and removed. When you ask for one small tool and it wants to remove twelve packages, stop and look at what you actually typed. That one line has saved more servers than any backup.
What is the difference between
apt update and apt upgrade? Say this: apt update touches no installed software at all. It only downloads the newest catalog of what versions exist in the repositories, so apt knows what is out there. apt upgrade then reads that fresh catalog and actually installs newer versions of packages you already have. Run update and nothing on your system changes. Run upgrade without a fresh update first and you are shopping from last week catalog. That is why the two almost always run as a pair.The same job on Red Hat
On dnf the refresh is quieter because dnf checks freshness on its own before most operations. You can go straight to install:
$ sudo dnf install tree
Last metadata expiration check: 0:14:22 ago on Fri 03 Jul 2026.
Dependencies resolved.
================================================================
Package Arch Version Repository Size
================================================================
Installing:
tree x86_64 2.1.1-3.fc41 fedora 63 k
Transaction Summary
================================================================
Install 1 Package
Total download size: 63 k
Is this ok [y/N]: yNotice dnf prints a clean transaction table and defaults the prompt to N. If you hit enter without thinking, nothing happens. That is a friendlier default than a blind yes.
Remove, and the trap called leftover config
On Debian, apt remove deletes the program but keeps its configuration files on purpose, so a reinstall picks up where you left off. That is helpful until you reinstall a package expecting a clean slate and get your old broken config back. When you truly want it gone, use purge:
$ sudo apt remove nginx # binary gone, /etc/nginx kept
$ sudo apt purge nginx # binary and /etc/nginx both gone
$ sudo apt autoremove # sweep up dependencies nothing needs nowMy verdict after years of this: on a server, reach for purge by default when you are removing something you know you are done with, and run autoremove right after. Half-removed packages with stale config are a common reason a fresh install behaves strangely, and the person debugging it a month later will not remember the remove that left the mess.
Where the packages actually come from
apt and dnf do not invent packages. They fetch them from repositories, which are servers holding thousands of signed packages plus an index describing them. On Debian and Ubuntu the list of repositories lives in /etc/apt/sources.list and any file under /etc/apt/sources.list.d/. On Red Hat it is the .repo files in /etc/yum.repos.d/. Every repository ships a cryptographic signing key, and the package manager refuses packages whose signature does not match. That is what keeps a hijacked mirror from feeding you a tampered openssl.
This is where I disagree with a habit half the internet teaches. Plenty of install guides tell you to run curl https://some-site/install.sh | sudo bash. That pipes a script straight from a web server into a root shell with no signature check, no record in the package database, and no clean way to remove it later. When a project offers a proper apt or dnf repository, use it instead. You get signature verification, you get apt remove and dnf remove that actually work, and you get security updates through the same channel as everything else. The curl-into-bash line is convenient exactly once, on the day you install. Every day after that it is a liability.
Back to that lock error from the top. On a fresh Ubuntu server, a background service called
unattended-upgrades starts at boot and grabs the dpkg lock to apply security patches. Your apt install arrives seconds later and finds the door bolted. The wrong fix is sudo rm /var/lib/dpkg/lock-frontend, which can leave the package database half-written if the other process is mid-transaction. The right move is to see who holds it and wait:sudo lsof /var/lib/dpkg/lock-frontendIf the command shows
unattended-upgr, give it a minute to finish and run your install again. It is not a bug. It is two writers being kept apart on purpose.When an install fails on dependencies
The second classic failure is unmet dependencies, usually after installing a .deb by hand with dpkg, which does not fetch dependencies the way apt does:
$ sudo dpkg -i someapp_1.4_amd64.deb
dpkg: dependency problems prevent configuration of someapp:
someapp depends on libssl3; however:
Package libssl3 is not installed.
$ sudo apt --fix-broken install
Reading package lists... Done
Correcting dependencies... Done
The following additional packages will be installed:
libssl3
Setting up someapp (1.4) ...The lesson is to let the manager do the fetching. Prefer sudo apt install ./someapp_1.4_amd64.deb with the leading ./, which tells apt to install a local file and pull its dependencies in one step. On the dnf side the same idea is sudo dnf install ./someapp.rpm, and it resolves the missing pieces for you rather than leaving a half-configured package.
One more Red Hat specific trap. Search for a common tool on a plain RHEL box and dnf answers No match for argument. The package is real, it just lives in the EPEL repository, which is not enabled by default. Install epel-release first and the same search suddenly finds it. On Ubuntu the parallel is the universe component, which modern releases already enable.
Looking under the hood with dpkg and rpm
When something is behaving oddly, the low level tools answer questions apt and dnf do not. The three you will reach for constantly: what is installed, which package owns a given file, and what files a package dropped on disk.
| Question | Debian (dpkg) | Red Hat (rpm) |
|---|---|---|
| List everything installed | dpkg -l | rpm -qa |
| Which package owns this file | dpkg -S /usr/bin/tree | rpm -qf /usr/bin/tree |
| What files did this package install | dpkg -L tree | rpm -ql tree |
| Install one local package file | sudo dpkg -i file.deb | sudo rpm -i file.rpm |
On any Debian or Ubuntu machine, install a tiny tool, see exactly what it placed on disk, then take it back out. Run these three lines:
sudo apt install -y treedpkg -L tree | grep binsudo apt purge -y treeThe verify step is the middle line. It should print
/usr/bin/tree, the actual binary the package installed. After the purge, run which tree and it prints nothing, which is how you confirm the removal was clean.History and rollback, where dnf pulls ahead
Here is a real difference that matters when a change goes wrong. dnf keeps a numbered history of every transaction and can undo one:
$ sudo dnf history
ID | Command line | Date and time | Action(s) | Altered
---------------------------------------------------------------------
14 | install httpd | 2026-07-03 09:41 | Install | 6
13 | upgrade | 2026-07-02 22:10 | Upgrade | 38
$ sudo dnf history undo 14
Undoing transaction 14, from Fri 03 Jul 2026
Erase httpd and 5 dependencies
Is this ok [y/N]:That undo reverses the exact set of packages a transaction changed, dependencies included. apt has no true equivalent. It logs what happened in /var/log/apt/history.log, but reversing a change means reading that log and undoing it by hand. If clean rollback matters to you and you are choosing a distribution family, this is a genuine point in the Red Hat column, not a detail to wave away.
One habit worth building on either family: when you want to keep a specific package from being upgraded, pin it rather than skipping upgrades entirely. On Debian that is sudo apt-mark hold nginx, and sudo apt-mark unhold nginx to release it. Freezing a whole system for the sake of one package is how machines drift years behind on security patches.
Questions I actually get
Should I use apt or apt-get?
For typing at the keyboard, use apt. It has the progress bar and the cleaner output. In scripts, prefer apt-get because its output and options are frozen for stability and will not change under you between releases. Both drive the same engine underneath.
What is the difference between apt upgrade and apt full-upgrade?upgrade will never remove an installed package to complete an upgrade, so it sometimes holds packages back. full-upgrade, once called dist-upgrade, is allowed to remove packages when a new version needs it. On a stable release full-upgrade is usually what you want; the removals it makes are deliberate.
Is snap or flatpak a replacement for apt?
No, they sit alongside it. apt and dnf manage the system itself, the kernel, the libraries, the services. Snap and Flatpak package desktop applications with their own bundled libraries. Use the system manager for anything a server runs; reach for Snap or Flatpak when you want a newer desktop app than the distro ships.
Why does apt say packages were kept back?
An upgrade found a newer version but installing it would require removing or adding a package, which plain upgrade refuses to do. Run sudo apt full-upgrade to let it complete the change, or apt list --upgradable first to see what is waiting.
How do I clear space that packages are using?sudo apt autoremove drops dependencies nothing needs anymore, and sudo apt clean empties the downloaded package cache in /var/cache/apt/archives. On dnf the pair is sudo dnf autoremove and sudo dnf clean all. On a tight root partition these two commands often free more than you expect.
Packages are the moment Linux stops feeling like a locked box and starts feeling like a system you assemble on purpose. Learn the six verbs, read the summary line before you confirm, and keep your software coming from signed repositories rather than a script piped into a root shell. Next in the series we take the services these packages install and put them under systemd, so software starts on boot and stays up on its own. Open a terminal and install something small right now; the muscle memory is the whole point.
References
· apt(8) manual page, Debian
· dnf5 command reference
· Fedora, replacing dnf with dnf5
· Cloud for Beginners: The Complete Guide
· VMware for Beginners: The Complete Guide
About The Author
DrJha