Mastering RPM Installation on Ubuntu
Some enterprise utilities, legacy drivers, and even selected commercial software are only distributed in RPM format, with no .deb
available. Unexpected, but not uncommon—especially with vendor hardware agents or security clients targeting Red Hat–centric environments. Recompiling or repackaging from upstream source? Often impractical on production or controlled endpoints. Direct install isn’t an option: RPMs and DEBs are structurally incompatible, and dependency resolution fundamentally differs.
Problem Statement
Installing RPMs on Ubuntu is an edge case, but occasionally unavoidable. A typical failure:
dpkg -i some-tool.rpm
dpkg-deb: error: 'some-tool.rpm' is not a Debian format archive
Blind extraction or forced installs (rpm -i
) rarely work. Result: partial deployments, mismanaged dependencies, broken upgrades. The correct approach: convert the package, or containerize/virtualize the RPM payload.
Method 1: Converting RPMs to DEBs with alien
alien
(v8.95 as of Ubuntu 22.04 LTS) converts .rpm files to .deb format, providing a legitimate way to get an RPM-installed workload into the /var/lib/dpkg
database. Conversion isn't foolproof—pre/post-install scripts, SELinux policies, or custom triggers may not translate perfectly. But for most payload-only packages (e.g., CLI utilities, binaries), it works.
Install prerequisites:
sudo apt update
sudo apt install alien dpkg-dev debhelper build-essential
Note: dpkg-dev
and debhelper
resolve most basic build logic alien uses for scripts/conversion.
Convert:
sudo alien --to-deb --scripts package-2.1.0.rpm
The --scripts
flag instructs alien to carry over RPM %post
and other scriptlets into the DEB’s maintainer scripts, though not all RPM scriptlets are compatible with DEB preinst/postinst idioms.
Install the resulting DEB:
sudo dpkg -i package_2.1.0-2_all.deb
sudo apt-get install -f
apt-get install -f
will attempt to resolve and install any outstanding dependencies which the new DEB declares.
Side note: Sometimes, a conversion will produce a DEB that installs but fails to run, usually due to missing libraries. Use ldd /usr/bin/the-binary
to verify runtime library links, and apt-file search
to locate Ubuntu packages that provide them.
Real-World Example: Dropbox RPM
Scenario: Dropbox's official Linux package for Fedora, unavailable in .deb (variant as of mid-2023):
wget https://linux.dropbox.com/packages/fedora/dropbox-202.4.0.rpm
sudo alien --to-deb --scripts dropbox-202.4.0.rpm
sudo dpkg -i dropbox_202.4.0-2_all.deb
sudo apt-get install -f
Known issue: Dropbox tries to register a systemd service via postinst, which may fail silently if systemd service directories differ; always check the service registration.
Method 2: Inspecting RPMs Directly
Sometimes, you don’t need a full install—just validation or file extraction. The rpm
utility is available on Ubuntu for reading, not writing the DB.
Install:
sudo apt install rpm
Usage:
rpm -qpi some-driver-1.8.4.rpm # Show header & metadata
rpm -qlp some-driver-1.8.4.rpm # List package file contents
Extract contents, bypassing package managers entirely (advanced):
rpm2cpio some-driver-1.8.4.rpm | cpio -idmv
This unpacks payload into the current directory. Manual placement of binaries/libraries is required (not recommended for system packages, but can be useful for statically linked tools).
Dependencies: The Real Bottleneck
Converted packages may expect SELinux, specific sub-libraries, or GLIBC versions. When faced with “unmet dependencies”:
- Search for Ubuntu-native packages matching RPM requirements (
apt-cache search
). - Avoid blindly installing .so libraries—prefer package management.
- For drivers or vendor agents, check if a Snap, Flatpak, or AppImage container exists.
- Some RPMs only work on compatible kernel headers (RHEL7 vs. Ubuntu 22.04 diverge significantly); inserting a mismatched kernel module can brick boot.
Practical Tips & Common Pitfalls
- Always use
--scripts
with alien for packages that install services or run configuration tasks. - Review converted scripts by extracting the DEB and checking
DEBIAN/postinst
orprerm
. - Regression-test on a VM or container first; file conflicts or misfiled conffiles can disrupt critical systems.
- Never use
rpm -i
to install RPMs on Ubuntu. This writes outside dpkg/apt’s knowledge and typically leads to package DB inconsistency. - After installation, run
apt-mark manual <package>
if you want to avoid it being removed byapt autoremove
.
Summary Table
Approach | Use case | Limitations |
---|---|---|
alien (.rpm → .deb) | Most RPM applications, simple binaries | Scripts may break; not foolproof |
rpm2cpio (extract only) | Unpack single binaries or libraries | No updates, manual integration |
rpm install | (Don’t: unsupported, risk of system breakage) | Breaks dpkg, unmet dependencies |
A Non-obvious Tip
When alien-generated DEBs fail at install time with vague errors, unpack both the RPM and the resulting DEB, and compare scripts and directory trees line by line. Sometimes missing environment variables or hard-coded paths (e.g., /usr/lib64/
) are easily fixed by hand-editing and rebuilding the DEB (dpkg-deb --build
).
In summary: Interoperability between RPM and DEB ecosystems isn’t seamless. alien
is effective for stateless tools and simple applications, but always verify on non-critical systems first. For stateful or kernel-level packages, containerization or direct source compilation is preferable.
Further reading:
If your workflow needs automation or you hit a tricky postinstall script, open a detailed issue—edge cases are common in this space.