DNF cannot satisfy a package dependency plan · Linux Fix Lab

Symptoms & scope

DNF reports nothing provides a required capability.
A provider exists but cannot coexist with the installed package set.

Relevant environment

RPM-based system with DNF5; DNF4 has similar concepts but some options differ. Cached queries may reflect old repository metadata.

Recognizable messages (synthetic examples)

 - nothing provides libexample.so.3()(64bit) needed by example-app-2.0-1.x86_64 from vendor-repo

Check enabled sources, release and architecture; this wording can also occur with other libsolv-based package managers.

 - package example-app-2.0-1.x86_64 requires example-lib >= 3, but none of the providers can be installed

Read the following conflicts and constraints; an existing provider is different from a missing repository package.

Possible causes

These are possible explanations, not a confirmed diagnosis. Several independent faults can coexist.

A required repository may be disabled, missing this release or filtered by architecture/version policy.
Third-party or partially upgraded packages may require an incompatible dependency version.

Diagnose safely

Run one command at a time in the relevant session. Read the explanation first. Uppercase placeholders need your own values; tools and privileges vary by distribution. These commands are displayed here and never executed by the website.

Check 1

Replace PACKAGE_NAME with the installed package named by the solver; reads RPM requirements without starting a transaction.

rpm -q --requires PACKAGE_NAME

Interpret the result: Compare the exact capability, soname and version expression. A package name alone is not always the dependency the solver needs.

Check 2

Replace CAPABILITY with the exact solver requirement and keep shell quoting for parentheses or comparison operators. Reads cached metadata only.

dnf5 --cacheonly repoquery --whatprovides 'CAPABILITY'

Interpret the result: No result can mean no cached provider or missing/stale cache; it does not prove the publisher has no current package. Compare provider release and architecture.

Evidence-guided next steps

Correct the responsible repository or package release

If the package comes from a source for another OS release, save repository configuration and use the maintainer’s supported release source or package. Refresh metadata, preview the intended transaction with --assumeno and apply it only after checking replacements and removals.

Precautions: Do not install arbitrary RPMs from another release or use --allowerasing without inspecting every proposed removal.

Recovery / rollback: Restore the saved source and coherent pre-transaction snapshot; reverting only a repository file does not undo installed version changes.

Did this solution help you?

Share this solution #

Synchronize a reviewed affected package set

If sources are correct but installed versions differ from their supported repository set, preview dnf5 --assumeno distro-sync PACKAGE_NAME for the affected package. Review its dependency transaction, including any downgrade, before an administrator applies it without automatic yes.

Precautions: Distro-sync may downgrade packages; application data migrations may not be reversible. Do not use skip-broken to conceal an unresolved dependency.

Recovery / rollback: Restore the saved application data/configuration and coherent snapshot if a downgrade causes incompatibility; history undo depends on package availability and is not guaranteed.