RakuOS 2026.08.22: meet rum, our own package manager

This release's headline is a big one: RakuOS now has its own native package manager, rum. It's not a side project sitting off to the edge of the system, it's the backend now powering package installs and removals in both RakuOS Software and RakuOS Welcome, and it's steadily taking over from dnf everywhere else too.

Why RakuOS needed its own package manager

RakuOS is an image-based, bootc-driven system. The base OS lives in an immutable, atomically-updated image, and anything you install on top of it lives in a writable overlay layered underneath. That's a fundamentally different model from the traditional mutable root filesystem dnf was designed around, and for months RakuOS made it work by wrapping dnf in shell scripts: shuffling packages into the overlay, merging rpmdb state by hand, patching over the seams.

It worked, but it was always a wrapper bolted onto a tool that doesn't know RakuOS's overlay exists. Keeping the base image's packages untouched, tracking what you explicitly installed versus what came from the image, making sure the database the resolver is looking at actually reflects reality: all of that had to be faked from the outside, in shell, around a resolver that has no concept of any of it.

rum exists so we can stop faking it. It's a package manager designed overlay-first, where "install this on top of the immutable base and never touch what's already there" isn't a workaround bolted on afterward. It's just the default behavior.

What rum actually is

rum is a full native package manager written in Rust, not a thin dnf shim. It has its own repository metadata handling, its own dependency resolver built on libsolv (the same SAT-solving engine dnf5 itself uses under the hood), and its own transaction and rpm invocation layer. It speaks the same repo formats and largely the same command surface as dnf/dnf5 on purpose: rum install, rum remove, rum upgrade, rum search, rum history undo, rum repoquery, and so on all work the way you'd expect if you've used dnf before. Full command-and-flag parity with dnf5 is the goal, not a reduced subset. If you're used to reaching for a specific dnf flag, chances are rum already supports it, and if it doesn't yet, it's on the list.

What it adds on top is the part dnf was never built for. On a real RakuOS system, rum keeps a base rpmdb snapshot from the image completely separate from its own overlay rpmdb, so there's no fragile merging or diffing needed to figure out what came from the image versus what you installed yourself, it just knows. Upgrading, reinstalling, or downgrading a package never touches the base image, even if you name a package that also happens to live there; everything you do lives entirely in the overlay, where a soft reset can cleanly wipe it clean if you ever want to start over. And the resolver itself actually understands the system it's running on: protected packages, multilib and cross-arch consistency, weak dependencies, instead of treating those as edge cases to patch around later.

Outside of a RakuOS system entirely, inside a distrobox container, or while building an image, rum notices and just behaves like a normal package manager against a single database. Same binary, same commands, the right behavior for whatever it's actually running in.

None of this has been built in a vacuum. rum has been getting exercised hard throughout this cycle against real Fedora repository data and real RakuOS overlay systems, not just synthetic test cases, while its libsolv-backed resolver, module and group support, and offline system-upgrade path all came together.

Now shipping: RakuOS Software and RakuOS Welcome both run on rum

This release, both of RakuOS's user-facing package installation surfaces switched their backend from the old dnf-wrapper scripts over to rum:

RakuOS Software, across all three of its frontends (GTK, COSMIC, and Qt), now installs and removes RPM packages through rum directly, and update checking runs through it too.

RakuOS Welcome, the first-run setup app that helps you get browsers, VPN clients, media apps, and drivers installed, does the same.

Under the hood, rakuos-core's own boot-time package handling made the switch as well, so the reconciliation logic that runs during boot is using the same tool as everything else now.

In practice this mostly just means things work better. Package operations triggered from a GUI now get the exact same overlay-correctness guarantees as running rum yourself from a terminal, instead of hoping a shell-script wrapper layer got it right. It also means a lot less duplicated logic scattered across the codebase: instead of three different frontends and several different apps each maintaining their own dnf-wrapper quirks, everything now goes through the same resolver and transaction code.

What's next

rum isn't done chasing full dnf5 parity yet. A handful of config options, an equivalent to dnf-automatic, and shell completions are still on the list, and they're being closed out incrementally rather than all at once. The commands you already know from dnf should keep working the same way in rum. If you find a rough edge, treat it as a gap worth reporting, not an intentional difference.

This is the direction package management on RakuOS is heading: one tool, built for the system it actually runs on, powering everything from the CLI to every GUI on top of it.

For the full list of everything else that changed this release, see the changelog.

To download visit: https://rakuos.org/download