Introducing Rum, RakuOS's own package manager
August 12, 2026 · Announcements
For most of its life, RakuOS relied on dnf, the same package manager every other Fedora based system uses. That worked fine for a plain Fedora install, but RakuOS is not a plain Fedora install. It is an image based, overlay driven system, and dnf was never designed with that model in mind. Over time the gap between what dnf assumes and what RakuOS actually needs became too wide to paper over, so we built Rum: a native package manager written from scratch specifically for how RakuOS works.
What Rum is
Rum is a package manager built in Rust that speaks the same rpm and repository formats as dnf and zypper, but resolves and applies transactions with its own dependency solver rather than wrapping dnf underneath. It still hands off the actual package installation to real rpm, since reimplementing cpio extraction, scriptlet execution, and signature verification is not something worth reinventing when rpm already does it correctly. What Rum owns is everything around that: repository metadata parsing and caching, dependency resolution, transaction planning, and the overlay awareness that makes RakuOS possible in the first place.
The problem with running plain dnf on RakuOS
RakuOS images are built from an immutable base layer, with user installed packages tracked separately in an overlay. This is what lets RakuOS update atomically and roll back cleanly. dnf, however, was built around the assumption of a single, unified rpm database describing everything on the system. On an overlay based system, that assumption breaks down in a few specific ways.
The most serious was dependency resolution. When you asked dnf to install something, it needed to know what was already satisfied by the base image so it did not try to reinstall or shadow packages that were already there. Getting this right meant either merging the base and overlay databases at query time, which is fragile and prone to staleness, or working around dnf's assumptions with wrappers and shims that grew more complicated with every edge case we ran into.
How Rum solves it: split mode
Rum's core design decision is what we call split mode. Instead of merging the base image's rpm database with the overlay's, Rum keeps two separate, always accurate databases: one read only snapshot of what the base image provides, and one that Rum owns and writes to for everything installed on top. Rum's resolver treats these as two independent sources of truth and unions them at query time, so it always knows precisely what is base provided versus overlay provided without ever needing to diff or reconcile the two.
This sounds like a small technical detail, but it removes an entire class of bugs. Packages no longer get shadowed by mistaken overlay installs. Upgrades, downgrades, and reinstalls only ever touch the overlay, never the base layer, which is exactly the guarantee an image based system needs to stay reliable. And because Rum's resolver is aware of this split from the start, rather than working around a single merged database, dependency conflicts between what the base already provides and what the overlay wants to add get resolved correctly and predictably.
Split mode also let us fix problems that would have been much harder to reach from inside a dnf wrapper. As one example, cross package file triggers, the mechanism rpm uses to regenerate things like compiled GSettings schemas, icon caches, and desktop databases after a relevant package is installed, only fire when the triggering package lives in the same rpm database as the transaction. Under split mode that is not automatically true, since the package doing the triggering (say, glib2) lives in the base snapshot while the transaction runs against the overlay database. Because Rum owns the whole transaction pipeline, we could add a lightweight, targeted post install step that detects when a transaction touches one of these paths and reruns the appropriate regeneration command, restoring the exact behavior a real dnf transaction on a single database would have given you for free.
Where Rum stands today
Rum is currently running on RakuOS's staging images, where it is being exercised against real, full package sets rather than synthetic test cases, That is deliberate. A dependency resolver only proves itself under real, messy repository data, with obsoletes, conflicts, multilib packages, and version pinned requires all interacting at once. Staging is where we catch the cases that a small hand written test suite never would, and several real bugs, including subtle SAT solver interactions around obsoletes based package replacement, have already been found and fixed this way before ever reaching a stable image.
Not just for RakuOS
Although Rum was built to solve RakuOS specific problems, split mode is only active when it detects a real RakuOS overlay system. Everywhere else, in a plain Fedora container, a distrobox, or an image build environment, Rum automatically runs in standalone mode and behaves like an ordinary package manager against a single rpm database, exactly like dnf or zypper would. Rum ships with compatibility shims that let it act as a drop in replacement for both, accepting the same commands and flags you already know. That means the same dependency resolver we rely on for RakuOS itself is also available as a genuinely useful package manager on any rpm based distribution, independent of the overlay problem it was originally written to solve.