apt vs yum vs dnf vs pkg: Practical Package Management Guide

You Keep Forgetting the Right Command on Each Server

If you jump between Debian/Ubuntu, Rocky/Fedora/RHEL, and FreeBSD, package management can feel like muscle-memory whiplash.
One server wants apt, another wants dnf (or yum), and that FreeBSD box just throws pkg at you.

This guide is for admins and devs who:
– SSH into different boxes all week
– Just want to install, remove, and update stuff without Googling every time
– Need to avoid breaking production because of one bad upgrade

We’ll walk through the basics of apt, yum/dnf, and pkg side-by-side, using only what’s in the source.
Short, practical, and focused on safe workflows.

1. Know Your Package Manager on Each System

First thing: you need to know which tool you should be using on the box you’re logged into.
Modern Unix-like systems ship with a default package manager that talks to their own repositories.

From the source, the main mapping looks like this:

Debian / Ubuntu
Use: apt as the main interface
Under the hood: also has dpkg for low-level package handling
Extra tools: apt-get (scripting), apt-cache (detailed queries)
Rocky Linux / Fedora / RHEL
Use: dnf on current systems
Legacy: yum on older systems
FreeBSD
Use: pkg

If you’re not sure what family a server belongs to, you can usually spot it from the package tool available:

apt exists → Debian/Ubuntu family
dnf or yum exists → RHEL/Fedora/Rocky family
pkg exists (and it’s FreeBSD, not some random Linux variant) → FreeBSD

Pick the right one and stick to it for that server.
Mixing tools across families is how you end up with broken systems.

2. Repositories: Where Your Packages Come From

All these tools talk to repositories: central locations that store package files and metadata.
If your repo configuration is wrong, nothing else works properly.

Debian/Ubuntu: `sources.list` and `add-apt-repository`

On Debian and Ubuntu, repository configuration is handled through sources.list and related files.

Key points from the source:
– Main config is sources.list
– You can also use add-apt-repository to add repos (like PPAs) more easily

Typical workflow:
1. Add a repository (e.g., third-party software)
– Use add-apt-repository so you don’t manually edit everything
– Why it matters: avoids syntax errors and handles some details for you
2. Update package lists
– Run apt to refresh available package metadata

When changing repositories, do it on staging first, not production.
Repository mistakes can lead to weird dependency mixes.

Rocky/Fedora/RHEL: `/etc/yum.repos.d/` and `dnf config-manager`

On RHEL-style systems using dnf or yum, repos are configured using files under /etc/yum.repos.d/.
Each repo usually has its own .repo file.

From the source:
– Repo configs live in /etc/yum.repos.d/
– You can use dnf config-manager to manage them

Typical workflow:
1. Drop a .repo file into /etc/yum.repos.d/ (from a vendor, for example)
2. Or use dnf config-manager to enable/disable or add repos
3. Update metadata with dnf so the system knows what’s available

Again, test repo changes in a safe environment first.
Wrong repos + dnf upgrade in production = long night.

FreeBSD: `pkg` Repos

The source just tells us that FreeBSD uses pkg.
We know there are repositories behind it, but we’ll stay within the source: pkg talks to its configured repos and pulls packages from there.

Whenever you touch repository settings on any platform:
– Make a copy of the old config file
– Note what changed (and where) for easy rollback

3. Installing, Removing, and Updating Packages Safely

Now to the daily stuff: install, remove, upgrade.
We’ll line up what the source tells us about each tool.

Debian/Ubuntu: `apt`, `apt-get`, and `apt-cache`

On Debian and Ubuntu, apt is your main interface.

From the source:
– Use apt for normal operations
– Use apt-get for scripting
– Use apt-cache for low-level queries like policy and depends

Typical flow:
1. Search and inspect
– Use apt-cache for detailed info like dependencies and policies
– Why: helps you understand what else will be pulled in
2. Install
– Use apt interactively on the shell
3. Remove
– Use apt to remove packages you no longer need

When scripting or automating (cron, CI, etc.), prefer apt-get.
It’s more stable for non-interactive use.

Rocky/Fedora/RHEL: `dnf` and legacy `yum`

On RHEL-type systems, the source makes it clear:
– dnf has replaced yum
– On older systems, yum is still there
– To remove packages, use dnf remove (or yum erase on legacy systems)

Typical flow:
1. Check a package using dnf’s query capabilities (list/info)
2. Install the package with dnf
3. Remove a package with:
– dnf remove on modern systems
– yum erase if you’re stuck on a really old setup

On any RHEL-style server, get in the habit of using dnf first.
Only fall back to yum when the system really is that old.

FreeBSD: `pkg`

The source states:
– FreeBSD uses pkg

So your basic install/remove/update operations all go through pkg.
The main idea is the same: it talks to repos, handles dependencies, and manages installed software.

Safety Habits Before You Hit Enter

The source mentions some critical production safety habits:

Use dry runs or --assumeno when possible
Purpose: see what will happen before it happens
Schedule upgrades in change windows
Don’t run major updates in the middle of business hours
Verify services after applying updates
Make sure web, database, and background services are actually running after your upgrades

Even for simple package installs, get used to checking what else is going to change.
A dependency upgrade can be the hidden breaking point.

4. Handling Repositories and GPG Signatures Correctly

Repositories and packages are usually signed with GPG keys.
This is how your system verifies that a package really comes from who it claims.

If signatures are missing or wrong, you’ll see errors about keys or authenticity.
Here’s how the source says to handle them.

Debian/Ubuntu: Keyrings and `signed-by=`

From the source:
– GPG keys live in /usr/share/keyrings/
– Repos can reference keys via signed-by= in their configuration

So typical actions:
1. Vendor gives you a key file to trust
2. You place that key into /usr/share/keyrings/
3. You configure the repo entry to use signed-by= pointing to that key

Why this matters:
– It limits which key is used for which repo
– It keeps trust scoped instead of dumping keys globally

RHEL/Fedora/Rocky: `rpm –import`

For dnf/yum systems, the source says:
– Use rpm --import to add a GPG key

Basic idea:
1. Obtain the GPG key from the repository provider
2. Run rpm --import on that key file or URL
3. Then configure or enable the repo so dnf/yum can verify packages from it

If you skip this step, you’ll usually get signature verification errors when trying to install or update.

General Tips

Only import GPG keys from trusted sources
Keep notes of which key belongs to which repo
If you remove a repo, consider whether you still need the key

Configured correctly, these keys reduce the risk of tampered packages reaching your boxes.

5. Rollbacks, History, and Recovery Options

Sometimes you install or upgrade something and immediately regret it.
How far you can roll back depends heavily on the tool.

`dnf`/`yum`: Transaction History and Undo

From the source:
– dnf history list shows transaction history
– dnf history undo allows rollback of installs and upgrades

This is a big advantage on dnf-based systems:

Typical recovery pattern:
1. Something breaks right after a dnf operation
2. Check what happened with dnf history list
3. Use dnf history undo on the relevant transaction to roll it back

It’s not a excellent time machine, but it gives you a structured way to back out specific operations.

apt and pkg: No Built-in Transaction Rollback

The source is clear:
– apt and pkg do NOT offer built-in transaction rollback

So on Debian/Ubuntu and FreeBSD, you can’t just hit an “undo last transaction” button.
You have to:
– Manually remove or downgrade packages
– Or restore from snapshots/backups at the system level (ZFS, LVM, VM snapshots, etc.)

This is why safe habits up front are so important, especially with apt and pkg.

If you’re managing critical Debian/Ubuntu or FreeBSD servers:
– Try updates in staging first
– Use filesystem or VM snapshots before big upgrades

Dependency Problems: Fixing Broken States

The source gives two specific tools for dependency issues.

On Debian/Ubuntu:
– Use apt --fix-broken install
– Purpose: resolve broken dependency situations after installs/updates

On dnf-based systems:
– Use dnf distro-sync
– Goal: sync installed packages to what’s in the currently enabled repos
– Always review with a dry run or --assumeno before letting it change things

When a system feels “half-updated” or dependencies look inconsistent, these two commands are your first moves.

6. Production-Friendly Upgrade Workflow

Let’s combine the best practices from the source into a simple, repeatable workflow for production servers.
This works regardless of whether you’re on apt, dnf/yum, or pkg.

1. Plan and Schedule

Use change windows
Do your updates when downtime or short hiccups are acceptable
Let stakeholders know

2. Test in Staging First

Apply the exact same repo changes and upgrades on a staging system
Verify apps and services there before touching production

3. Preview Changes

The source recommends:
– Use dry runs or --assumeno

So the pattern is:
– Run the upgrade/install with “no actually do it yet” options
– Carefully read which packages will be installed, upgraded, or removed

If it wants to remove half your stack, stop and investigate.

4. Apply Changes Cautiously

On dnf systems, know you have dnf history undo as a backup tool
On apt/pkg systems, be extra cautious since you lack built-in rollback

5. Verify Services Afterward

From the source:
– Verify services after applying updates

Make this muscle memory:
– Web server responding?
– Database running?
– Background jobs/cron workers alive?

Don’t just trust that “no errors in the terminal” means “everything is fine.”

Quick Recap

apt is your main tool on Debian/Ubuntu; use apt-get for scripts, apt-cache for deeper info
dnf is the modern tool on RHEL/Rocky/Fedora; yum is only for older systems
pkg manages software on FreeBSD
Repos live in sources.list/add-apt-repository on Debian/Ubuntu, and /etc/yum.repos.d/ with dnf config-manager on RHEL-style systems
Verify repos and package signatures with keyrings/signed-by= on apt and rpm --import on dnf/yum
dnf history undo provides transaction rollback; apt and pkg do not, so plan accordingly
Fix dependency mess with apt --fix-broken install on Debian/Ubuntu and dnf distro-sync on dnf-based systems
In production, always preview changes, schedule updates, and check services after upgrades

If this worked for you, keep CrushEdge handy for the next fix.