When a Fedora upgrade stalls: what --best and --skip-broken actually do to your system

You run sudo dnf upgrade on a Fedora workstation, and instead of a clean transaction you get a wall of dependency conflicts: a third-party repo package wants a library version that Fedora's repos haven't shipped yet. The upgrade refuses to proceed. The two flags people reach for — --best and --skip-broken — look interchangeable, but they push DNF's solver in opposite directions. Knowing which one you want is the difference between a strict upgrade and a quietly partial one.

The solver's default posture

DNF resolves upgrades by evaluating every candidate package against a dependency graph: what each package requires, provides, conflicts with, and obsoletes. Out of the box, Fedora ships with best=True effectively in play — DNF tries to install the highest available version of each package and treats failure to do so as an error rather than a suggestion. That's why one broken package in a third-party repo can block an entire system upgrade: the solver won't silently settle for an older version of something just to make the transaction succeed.

This strictness is deliberate. A package manager that quietly picks lower versions can leave you with mismatched libraries, half-upgraded desktop stacks, and bugs that are miserable to diagnose later. The strict default makes the failure loud and early.

--best vs --skip-broken: opposite trade-offs

The two flags adjust that posture in different directions:

• --best forces the strict behavior explicitly. If the highest-version candidate can't be installed for any reason, the transaction fails. Use it when you want a guarantee that nothing was silently downgraded or held back — for example, on a build machine where reproducibility matters.
• --skip-broken tells the solver to drop packages that can't be resolved and proceed with everything else. The upgrade succeeds, but some packages stay at their old versions. It's a recovery tool, not a policy.

The practical distinction: --best answers "did everything upgrade to the newest possible version?" with a hard yes or a failure. --skip-broken answers "upgrade whatever can be upgraded right now" and leaves the rest for later.

A worked example: unblocking a stalled upgrade

Say a RPM Fusion package depends on a library soname that hasn't landed in the Fedora updates repo yet, and your upgrade aborts. A reasonable sequence, run from a terminal with sudo privileges:

# 1. See what's actually broken before changing anything
sudo dnf check

# 2. Retry the upgrade, allowing the solver to skip unresolvable packages
sudo dnf upgrade --skip-broken

# 3. Review the transaction summary carefully before confirming.
#    DNF lists skipped packages — note them.

# 4. After the repos catch up, retry strictly
sudo dnf upgrade --best --refresh

Step 1 matters: dnf check reports missing dependencies and duplicate packages in the local RPM database, so you know whether the problem is your system or the repo metadata. Step 3 is where you exercise judgment — if the skipped list includes something security-relevant like openssl or a kernel, waiting is usually better than proceeding. Step 4 closes the loop: once the third-party repo publishes matching builds, a strict --best run confirms the system converges fully. The --refresh flag forces fresh metadata so you're not solving against a stale cache.

A word of caution: exact flag behavior and defaults have shifted across DNF versions and Fedora releases. Check your installed version with dnf --version and confirm the defaults in /etc/dnf/dnf.conf (look for best and skip_broken lines) before scripting around them, especially on a release-upgrade boundary.

Where plugins fit

DNF's plugin system adds capabilities without touching the core solver. Historically, plugins have handled things like delta RPM support (downloading only the binary differences between package versions to save bandwidth) and snapshot integration. You can list active plugins and toggle them in /etc/dnf/dnf.conf with the plugins setting. The useful mental model: flags steer the solver per-transaction, config steers it per-system, and plugins extend what transactions can do. If you administer several Fedora machines, keeping dnf.conf under configuration management is a better lever than remembering which flags to type.

The trade-off you accept with --skip-broken

Skipping broken packages is safe in the narrow sense — DNF won't install a package with unsatisfied dependencies — but it leaves your system in a mixed state. Old and new library versions can coexist in ways that confuse debugging later, and it's easy to forget the skipped list exists at all. Treat every --skip-broken run as creating a small debt: write down what was skipped, and schedule the strict re-run. If the same package keeps failing for more than a repo-sync cycle or two, the real fix is usually removing or replacing that package, not skipping it forever.

A habit worth adopting

Make sudo dnf check part of your post-upgrade routine, and default to strict upgrades on machines you care about. Reach for --skip-broken when you're blocked and understand what you're deferring, then verify convergence with --best once the repos settle. That loop — check, recover, verify — turns a stalled upgrade from an afternoon of forum searching into a ten-minute detour.