rum in RakuOS 45: package layers, and what sets RakuOS apart from other atomic distributions

In August we introduced rum, RakuOS's own package manager. Since then it has grown from "a dnf that understands our overlay" into the most ambitious piece of engineering in RakuOS. RakuOS 45, on the staging channel today and coming to everyone with its release, changes how your installed software is kept, updated and rolled back. This post explains what's changing, why, how it compares to other image-based distributions, and what we think makes it special.

The problem RakuOS 44 has today

RakuOS is an image-based system. The operating system itself is a signed, read-only container image that updates as a whole with bootc, and you can always go back to the previous one. That part works well.

Your own software is another story. On RakuOS 44, every package you install with rum or the Software Center goes into a single writable layer on top of /usr, the "overlay". It's simple, and it lets you install anything from the Fedora repos without a reboot. But one shared, writable layer has real weaknesses:

• An update can break what you installed, and you only find out after the reboot. A file you installed can keep hiding a newer copy the image ships, and a library your apps were built against can change underneath them. One staging tester rebooted into an update and lost their network connection; the only way back was rolling back the whole system.
• Rolling back the system doesn't roll back your apps. The overlay is shared, so going back to yesterday's image gives you yesterday's system with today's packages.
• There's no undo for a bad install. If installing or updating a package breaks something, the fix is to remove it and hope, or reset and reinstall everything.
• Anything running as root can write anywhere in the overlay, including scripts and installers that were never meant to touch your system files.

RakuOS 45 fixes all four.

Package layers

In RakuOS 45, rum installs your packages into package layers: separate trees under /var/lib/rakuos/layers, stacked read-only on top of the system image. rum decides where each package goes:

Layer	What's in it
system	RakuOS's own settings, like your sudo and coreutils choices
local	software you installed yourself (make install and the like)
local-rpm	packages you installed from a downloaded .rpm file
override	system packages you replaced or removed
user	everything else you installed
devel	compilers, development headers and build tools
drivers	kernel drivers and what they need
(bottom)	the RakuOS image itself

You still just run sudo rum install or click Install in the Software Center. What changed is everything rum does around that.

Every layer has its own package database

Each layer that holds packages keeps its own rpm database, inside the layer. rum reads all of them together with the image's when it works out dependencies, the same way it already reads the image's and its own today. Because a layer's package records live with its files, any layer can be moved to an earlier version with its packages and its records together, consistently.

Every change is a new generation

A layer is never changed in place. When you install something, rum:

1. builds the change in a private copy of /usr that only it can see, where rpm and the package scripts run as usual;
2. copies the affected layers into a new generation (unchanged files are shared, not duplicated, so this costs almost nothing) and applies the change there;
3. switches to the new generation and swaps the new /usr in underneath your running system.

The change shows up right away, without a reboot, and programs that are already running keep working. If anything fails along the way, nothing changes at all. There's no half-installed state to clean up.

Only rum can change your layers

/usr is read-only on RakuOS 45, and so is the folder the layers live in. Scripts, installers and stray sudo cp commands get "Read-only file system". rum is the only program that writes there, and it opens a private, writable view only for the duration of a change. Programs that need to write into /usr, like a script that patches an installed app, run through rum layer-run, so their changes land in a layer, are tracked, and can be undone like any other change.

Undo, from the terminal, the app, or the boot menu

Every change keeps the set it replaced: the last five per system version.

rum layer-history          # what changed, newest first: "replaced by rum install htop  +htop"
sudo rum layer-rollback    # go back, right now

RakuOS System's Deployments page shows the same list with a Go Back to This button. A rollback is itself undoable: the set you leave becomes the newest entry.

If a change keeps your desktop from starting, the boot menu has a RakuOS previous package layers entry that starts with the set from before. And if your system fails to finish starting twice in a row after a package change, RakuOS goes back to the previous set by itself on the third try.

Updates are prepared before you reboot

When a new RakuOS image is downloaded, rum immediately builds your layers for it: it drops packages the new image now includes, upgrades the rest against the new image, and moves your drivers to the new kernel's builds. Your running system isn't touched. When you reboot, the new image starts with layers made for it. While an update is waiting, the Software Center stops listing separate package updates, because the update already covers them.

Every system version keeps its own apps

RakuOS keeps a record of which layer generations belong to which installed system version. Reboot into an update and you get the layers prepared for it. Pick the previous version in the boot menu and you get the apps you had with that version, not today's. Go forward again and today's come back. When the system removes an old version, the layers that only it used go with it.

Change system packages without building your own image

sudo rum override replace mesa-vulkan-drivers   # a newer build from the repos, or a downloaded .rpm
sudo rum override remove gnome-tour             # hide a system package you don't want
sudo rum override reset gnome-tour              # back to the system's own version

Overrides live in their own layer, follow you through updates, and step aside on their own once the image ships the version you replaced it with. rum refuses to remove anything another package still needs, and it won't touch the kernel, glibc, systemd and the other packages the system can't start without.

How RakuOS compares

Image-based Linux has many good designs. Here's how RakuOS 45 lines up against the ones people ask us about most.

Fedora Silverblue, Kinoite and the other Fedora Atomic desktops (rpm-ostree). rpm-ostree pioneered much of what we admire: a versioned, read-only system, per-version package layering, and override replace/remove. But a layered package is built into a new system version and appears after a reboot (live application is limited and experimental), and the Fedora project increasingly recommends building your own image when you need more. RakuOS 45 keeps per-version packages and overrides, and adds live installs, instant undo and an automatic fallback, all from ordinary Fedora-compatible repos.

bootc-based systems. bootc is the foundation RakuOS itself is built on. Its own answer to installing software on a running system is a temporary writable /usr that disappears at the next boot, or building a custom image. RakuOS 45 gives you persistent, tracked, rollback-able installs on top of the same bootc image, without writing a Containerfile.

Universal Blue and Bazzite. Great images, built on the same Fedora technology. They steer users away from layering packages (Flatpak, Distrobox and Homebrew instead) because of the drawbacks above. On RakuOS, installing an RPM is a first-class, safe operation again, so you can use whichever fits the job.

openSUSE Aeon and MicroOS. These apply changes into a new Btrfs snapshot with transactional-update and need a reboot for every package change, with rollback by snapshot. RakuOS applies changes live and rolls back per change or per system version, independent of the filesystem.

NixOS. Nix gets a lot right: generations, rollback, atomic changes. RakuOS 45 borrows those ideas directly. What it doesn't ask of you is learning the Nix language, giving up the standard Linux directory layout, or packaging software differently. You keep plain RPMs and the commands you already know. Nix still does something we don't: fully reproducible, isolated package sets where two versions of a library can live side by side. That's a deliberate trade-off on our part, not an oversight.

Vanilla OS, SteamOS and other A/B systems. Two system copies with a switch between them work well for the operating system itself, and SteamOS in particular simply wipes any packages you add on its next update. RakuOS treats your software as something that should survive updates, rollbacks and resets.

What sets RakuOS apart

Put together, RakuOS 45 is the only desktop system we know of that offers all of these at once:

• an immutable, signed system image with whole-system updates and rollback;
• live package installs from regular RPM repositories, with no reboot;
• atomic changes: every change succeeds completely or doesn't happen;
• generations and instant undo for your packages, from the terminal, an app or the boot menu, with an automatic fallback when a change breaks booting;
• updates prepared before the reboot, against the exact image you'll boot;
• per-version package sets, so a system rollback really is a full rollback;
• overrides of system packages without a custom image;
• a read-only, rum-only package store that stray scripts can't damage;
• all of it behind familiar dnf-style commands.

The way we describe it internally: it's rpm-ostree's image and deployments combined with Nix-style generations and rollback, made from plain RPMs.

Why we're proud of rum

rum is written in Rust, and it doesn't reinvent what already works: dependency solving uses libsolv, the solver behind dnf5 and zypper; downloads use librepo; and packages are installed by rpm itself. rum owns what sits between them, and in RakuOS 45 that's a lot: per-layer package databases resolved as one system, transactions staged in private mount namespaces, generations swapped in under a running system, deployment and history records, and a boot-time fallback in the initrd. It's careful, layered engineering, and much of the work went into the cases you hope never to hit: failed installs, power loss mid-change, a broken update, an old record from before a format change. We think rum is becoming one of the most thoughtfully engineered package managers on any Linux system, and RakuOS 45 is where that shows.

Honest caveats

• It's on the staging channel. Package layers are in active testing on RakuOS 45 (staging) and will reach everyone with the RakuOS 45 release. RakuOS 44 keeps the current overlay until then.
• The first start reinstalls once. Moving to package layers rebuilds your installed packages one time, so keep the network connected. Staging testers will see this once more as the layer format settles.
• New releases still reinstall. Moving to a new RakuOS release (45 to 46) reinstalls your packages from the new release's repos on first start, as today.
• Your packages share one /usr. Unlike Nix, two versions of the same library can't be installed side by side.

Try it, and tell us what breaks

If you're on the staging channel, you already have most of this. The documentation explains it all, with commands: Package Layers. Found a problem? Tell us on the forum, Matrix or Discord, or file a bug at rakuos.org/bugs. Every report from staging makes RakuOS 45 better for everyone.