rpm checks dependencies but never resolves them. If a package needs something you
don’t have, rpm -i prints Failed dependencies and stops — it will not go find
the missing package. dnf (and yum, which is now a symlink to it) is the
layer that reads repository metadata, works out the full set, and hands the result to the same rpm
library. That is the entire distinction, and it is why the fix is almost always
dnf install ./package.rpm rather than rpm -i package.rpm.
Table of Contents
What a package says it needs
Two throwaway packages were built for this page: hwlib1, and hwdemo
which requires hwlib1 >= 1.0 plus a second dependency, hwlib2, that
was deliberately never built. You can read any package file’s requirements without installing
anything:
$ rpm -qp --requires hwdemo-1.0-1.noarch.rpm
hwlib1 >= 1.0
hwlib2
rpmlib(LargeFiles) <= 4.12.0-1
rpmlib(PayloadIsZstd) <= 5.4.18-1
$ rpm -qp --provides hwlib1-1.0-1.noarch.rpm
hwlib1 = 1.0
hwlib1 = 1.0-1
$ rpm -qlp hwdemo-1.0-1.noarch.rpm
/opt/hwdemo/app.txt-q queries, -p means "this argument is a package file, not an
installed package name". The rpmlib(...) entries are requirements on the rpm
implementation itself, not on other packages — that is how an old rpm refuses a package built with
a newer payload format.
The failure, and what it does not do
$ rpm -i hwdemo-1.0-1.noarch.rpm
error: Failed dependencies:
hwlib1 >= 1.0 is needed by hwdemo-1.0-1.noarch
hwlib2 is needed by hwdemo-1.0-1.noarchInstall the one dependency that exists and try again:
$ rpm -i hwlib1-1.0-1.noarch.rpm # exit 0
$ rpm -i hwdemo-1.0-1.noarch.rpm
error: Failed dependencies:
hwlib2 is needed by hwdemo-1.0-1.noarchrpm knew the name of the missing capability the whole time and still did not fetch it. It has no
repository configuration and no network layer; resolving that name to a package is dnf's job. Hand
the same file to dnf on a Fedora or RHEL host and it reads the enabled repos, finds a provider of
hwlib2, and installs the whole set in one transaction:
sudo dnf install ./hwdemo-1.0-1.noarch.rpmrpm 6 refuses unsigned packages by default
This one is new enough that most guides — including the earlier version of this page — predate
it. On rpm 6.0.2, the first attempt at installing a locally built, unsigned package fails before
dependencies are even considered:
$ rpm -i hwlib1-1.0-1.noarch.rpm
package hwlib1-1.0-1.noarch does not verify: no signature
$ rpm -E '%{?_pkgverify_level}'
allThe RPM 6.0.0 release notes state that "RPM defaults to enforcing signature checking", and that
"in the default configuration, packages built with RPM < 4.14.0 cannot be verified due to their
use of weak, obsolete MD5 and SHA1 digests." For a package you built yourself, the correct fix is
to sign it (rpmsign --addsign) or add its key with rpm --import. The
escape hatch is --nosignature, and every command below used it because these scratch
packages have no key:
$ rpm --nosignature -i hwlib1-1.0-1.noarch.rpm # exit 0Reaching for --nosignature on a package you downloaded is how you install something
that isn't what the vendor published. Sign your own, verify everyone else's.
What rpm -K actually prints, and how many fields -q can print
A since-retired FAQ on this site claimed checking a package with rpm -K or
rpm --checksig prints output including "md5 gpg OK" if the package isn't corrupt.
That's rpm4-era phrasing and it is wrong for rpm 6. A fresh throwaway unsigned package, checked
on this same rpm 6.0.2:
$ rpm -qpi hwsigdemo-1.0-1.noarch.rpm
Name : hwsigdemo
Version : 1.0
Signature : (none)
Build Host : [redacted].local
$ rpm -K hwsigdemo-1.0-1.noarch.rpm
hwsigdemo-1.0-1.noarch.rpm: digests SIGNATURES NOT OK
$ rpm --checksig hwsigdemo-1.0-1.noarch.rpm
hwsigdemo-1.0-1.noarch.rpm: digests SIGNATURES NOT OK(The Build Host line is the only edit to that output: this machine's real hostname
is replaced with [redacted] — rpmbuild records whichever host built the
package by default.) "md5 gpg OK" does not appear anywhere in that output. For an unsigned package,
"SIGNATURES NOT OK" is the whole story: there's no signature to check against, which is consistent
with the enforcement shown above. A vendor-signed package with an imported key would report
differently, but that wasn't tested here since no signing key exists for a throwaway build.
Separately, every field rpm -q can print is enumerated by one command:
$ rpm --querytags | wc -l
267
$ rpm --querytags | head -5
ARCH
ARCHIVESIZE
ARCHSUFFIX
BASENAMES
BUGURLEach of those 267 names works inside rpm -q --qf '%{TAG}'. --requires
and --provides, used above, are two of them;
rpm -q --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' hwlib1 is the one most build
scripts actually reach for instead of the bare package name.
--nodeps, and the mess it leaves in the database
--nodeps is the documented way to skip the dependency check. It works, and the
database then records a requirement that nothing on the system satisfies:
$ rpm --nosignature --nodeps -i hwdemo-1.0-1.noarch.rpm # exit 0
$ rpm -qa
hwlib1-1.0-1.noarch
hwdemo-1.0-1.noarch
$ rpm -q --requires hwdemo | grep -v rpmlib
hwlib1 >= 1.0
hwlib2
$ rpm -q --whatprovides hwlib2
no package provides hwlib2Nothing warns you again. The package is "installed" and will fail at runtime with a missing
library or a missing binary, at whatever moment is least convenient. Use --nodeps to
diagnose (does this actually need what it claims?), not to ship.
Removing packages
The dependency graph works in reverse too, which is the useful half:
$ rpm -e hwlib1
error: Failed dependencies:
hwlib1 >= 1.0 is needed by (installed) hwdemo-1.0-1.noarch
$ rpm -e --nodeps hwlib1 # exit 0 — hwdemo is now broken and rpm no longer says so
$ rpm -qa
hwdemo-1.0-1.noarchThe "(installed)" marker tells you the conflict is with something on the system rather than
something in the transaction. dnf remove would have offered to take
hwdemo with it; dnf autoremove additionally sweeps up dependencies
nothing else needs. Both of those start from knowing what is on the box —
listing what is installed with rpm -qa,
or dpkg --list on a Debian-family host is the query behind every answer above.
dnf, yum and dnf5, as of 2026
On Fedora 41 and later, dnf is dnf5: the Fedora change proposal states
that the /usr/bin/dnf symlink points to /usr/bin/dnf5, that "the dnf5
package will provide a /usr/bin/yum symlink for backwards compatibility", and that the old
implementation remains available as /usr/bin/dnf-3 and /usr/bin/dnf4.
So yum install still works and is still the wrong thing to type; it is a compatibility
shim, and dnf5's output and options are not identical to dnf4's.
alien on Debian and Ubuntu
The earlier version of this page offered alien program1.rpm as the Ubuntu route to
dependency handling. alien is still packaged — packages.ubuntu.com currently lists
version 8.95.9-1 in universe for 26.04 LTS — but it converts a payload; it does not
translate RPM capability names into Debian package names, so the resulting .deb
declares whatever alien could map and apt resolves against a different namespace. Its own man page
is blunt about the limits: "alien should not be used to replace important system packages, like
init, libc, or other things that are essential for the functioning of your system … packages from
the different distributions cannot be used interchangeably." Treat it as a way to extract files
from a vendor RPM, not as a dependency solver. If a native .deb or an apt repository
exists, use that. Conversion is also the wrong tool in the other direction: to produce an
RPM from a Debian host, rpmbuild installs
on Ubuntu and builds from a spec file, with no alien step involved.
Not tested here
This machine is macOS with rpm 6.0.2 from Homebrew and no RPM-based distribution anywhere.
Everything in a $ rpm block above is real output from real transactions against a
scratch --dbpath. Nothing involving dnf, yum,
dnf5, repository metadata, httpd, or alien was executed —
those statements come from the Fedora "Switch to DNF5" change proposal, the RPM 6.0.0 release
notes, and alien's own Ubuntu man page, and are cited rather than demonstrated. The alien section
in particular is documentation only: with no Ubuntu host here I did not run a conversion, so treat
"use the native .deb" as a recommendation rather than a measured result.
Check this yourself. Every command and every block of output on this page is reproduced by /verify/rpm-installation-dependencies.sh. Download it and run it: it creates its own scratch files, prints one line per claim, cleans up after itself, and exits non-zero if any claim here turns out to be wrong. If it disagrees with this page, the page is wrong.
