RPM Package Installation: Practical Notes from the Field
Installation of .rpm packages is still routine for engineers managing Fedora, RHEL, CentOS, openSUSE, or related Linux environments. Sometimes, vendor software only ships as an RPM, bypassing repository curation and CI-tested builds. That’s the gap RPM utilities fill—direct deployment, with the risk/reward balance in your hands.
Scenario: Getting a Bleeding-Edge Tool Installed
Consider you're on RHEL 9 and need a vendor diagnostic tool not yet in EPEL or AppStream. The vendor provides diagtool-2.5.8-1.x86_64.rpm. Here’s the exact, sequence-tested approach:
Step 1: Fetch the RPM
Typically, you’ll download the file either via browser, curl, or wget. Here’s a direct command:
wget https://vendor-site.com/diagtool-2.5.8-1.x86_64.rpm
Often the vendor will sign the package. Validate with their GPG key:
rpm --import https://vendor-site.com/RPM-GPG-KEY-vendor
rpm -K diagtool-2.5.8-1.x86_64.rpm
Check for an output like:
diagtool-2.5.8-1.x86_64.rpm: rsa sha1 (md5) pgp md5 OK
If you see NOT OK, abort. Compromised or incomplete RPMs are high-risk.
Step 2: Install—Resolve Dependencies Automatically
Preferred: Use dnf or yum. This way, dependency chains are resolved from configured repositories.
sudo dnf install ./diagtool-2.5.8-1.x86_64.rpm
or if dnf isn’t available (RHEL/CentOS < 8):
sudo yum localinstall diagtool-2.5.8-1.x86_64.rpm
Notice the ./ prefix. Without it, some package managers search remote repos, which may not find your local file.
Alternative: Direct install with rpm (not recommended for dependency-heavy packages):
sudo rpm -ivh diagtool-2.5.8-1.x86_64.rpm
-i: install-v: verbose (shows progress)-h: print hash marks for progress bar
This approach does not resolve dependencies.
Sample error on a minimal system:
error: Failed dependencies:
libfoo.so.2()(64bit) is needed by diagtool-2.5.8-1.x86_64
Gotcha: “rpm -i” leaves you manually hunting for libraries.
Step 3: Verification
Confirm installation:
rpm -q diagtool
Or for all RPMs:
rpm -qa | grep diagtool
To inspect files installed by the package:
rpm -ql diagtool
— useful for verifying binary locations or config paths.
Step 4: Removal
If required:
sudo dnf remove diagtool
# or for legacy systems
sudo rpm -e diagtool
Direct removal (rpm -e) does not check for dependents. On multi-user systems, always cross-check:
rpm -q --whatrequires diagtool
Summary Table: Core RPM Package Operations
| Task | Command Example |
|---|---|
| Install with dependency resolution | sudo dnf install ./package.rpm |
| Direct install (no dependency check) | sudo rpm -ivh package.rpm |
| Verify signature | rpm -K package.rpm |
| Query installed package | rpm -q packagename |
| List files in package | rpm -ql packagename |
| Remove package | sudo dnf remove packagename / sudo rpm -e packagename |
Non-Obvious Tips and Notes
- Corrupt RPM fix: Partially installed packages sometimes leave lock files (
/var/lib/rpm/__db.*). Remove stale locks and runsudo rpm --rebuilddbto reset the database. - Alternative approach: If multiple dependencies are missing and you’re in an air-gapped environment, resolve via
dnf download --resolve package.rpmon a system with network access, transfer, and install. - Legacy caution: Older systems may require
yum clean allbefore retrying failed dependency installations.
Note: Alternative formats like AppImage or Flatpak can sidestep RPM complexities, but RPM remains the default for system-level components and vendor enterprise software.
No method is perfect—manual RPM installation is robust, but requires vigilance. If the package routine breaks, check the logs (/var/log/dnf.log or /var/log/yum.log) for granular diagnostics.
Have a scenario that didn’t fit standard docs? Pin the error and environment succinctly for targeted troubleshooting.