How To Install Rpm In Ubuntu

How To Install Rpm In Ubuntu

Reading time1 min
#Linux#Software#OpenSource#Ubuntu#RPM#PackageManagement

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 or prerm.
  • 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 by apt autoremove.

Summary Table

ApproachUse caseLimitations
alien (.rpm → .deb)Most RPM applications, simple binariesScripts may break; not foolproof
rpm2cpio (extract only)Unpack single binaries or librariesNo 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.