Arch Linux 1023 CachyOS 14 Published by

Shelly ALPM 3.1.7, released today by Seafoam Labs, introduces RLPM, a native Zig reimplementation of Arch's libalpm that can dispatch package operations alongside the original library. Written under lead engineer Zoey Bauer, RLPM handles the full ALPM workflow while still letting users fall back to libalpm, though the authors openly admit complete compatibility remains unfinished. The project reached well beyond early adopters after CachyOS made Shelly its default GUI package manager in April 2026, amplifying RLPM's impact across a large out-of-the-box user base. With safety features like sealed memfd archives, Landlock/seccomp sandboxing, and openat2 path confinement, Shelly pairs an aggressive rewrite arc with surprisingly honest calls about its own limits.



Shelly ALPM 3.1.7 ships RLPM, a native Zig rewrite of Arch's package core

The Arch Linux package manager Shelly has shipped version 3.1.7, and this patch release quietly contains one of the most ambitious things it has ever attempted: a from-scratch reimplementation of libalpm, the library that pacman itself depends on. The authors call it RLPM. They are also being careful to tell you it is not finished yet.

Shelly is a GUI-plus-CLI package manager for Arch built by Seafoam Labs, the small open-source outfit that also maintains Devario and the Aqueous desktop environment. Unlike most alternatives, its team insists it does not wrap pacman. It links directly to libalpm instead, which gives it native performance and finer control. That distinction is the entire selling point, and it is exactly what makes RLPM such a move.

Screenshot_from_2026_08_12_18_29_27

Keep in mind that 3.1.7 dropped on October 16, 2026, the same day as this report, via a single commit on the development branch that the release notes described as just a "bug fix." The 3.1 line alone produced releases every few days from late August through mid-October. That cadence is fast, some would say reckless. Head here to the GitHub release if you want to read the full notes yourself.

A package engine, from scratch

The headline change is RLPM, a native engine written in Zig that can now dispatch Shelly's package operations. As the release notes put it, 3.1.6 leaned entirely on libalpm while 3.1.7 "can dispatch those operations to either libalpm or Shelly.Rlpm." Selecting RLPM does not silently fall back to libalpm. The two backends are genuinely parallel.

That matters because Shelly is no longer just a front-end. It is now building a second, competing implementation of Arch's package core. RLPM reads repositories, resolves dependencies, verifies and downloads archives, runs hooks and scriptlets, installs payloads, and updates the installed-package database, the full ALPM workflow, reimplemented by hand.

It still relies on the usual heavy lifting for the pieces it does not own. RLPM uses libarchive, SQLite, the shared HTTP and download stack, libcurl where needed, and GPG for signature verification. An "RLPM-only" build removes only the libalpm dependency, and the notes are blunt that "it does not make every dependency disappear."

What stands out more than the raw capability is how candid the release is. "RLPM is integrated and can execute package transactions, but complete libalpm compatibility remains unfinished," the notes say. A TSV compatibility ledger tracks what is missing, partial, or only representationally covered, and the team warns this does not certify parity across the public API, malformed inputs, or every production workflow. Record recovery, they note, "is not full package rollback." That sort of honesty is a nice change in a project this aggressive.

The engineering detail backstays the claims. Once an archive passes verification, Shelly copies it into a sealed, memory-backed file (memfd with sealing) so that swapping the original file on disk afterward cannot substitute a different archive. Privileged downloads can run under Landlock and seccomp restrictions while worker processes drop their credentials, and extraction paths are confined to the install root via openat2. That reads like a direct response to the usual package-manager attack surface: supply-chain substitution, path traversal, and lock races. Not bad for something the developers still call unfinished.

Rewriting the thing you consume

The arc here is the interesting part, and it is one you only understand if you follow the project. The original Shelly was written in C# and .NET, and it drew genuine pushback from parts of the Arch community. On Hacker News, comments on the CachyOS June 2026 release specifically questioned whether "Shelly is a good choice for the primary system package manager," with skepticism aimed squarely at it being compiled with .NET. Zoey Bauer, the project's lead engineer, pushed back in the forums and hammered the point that Shelly implements libalpm directly rather than wrapping pacman.

The team then did a full rewrite in Zig, landing v3.0.0 on July 30, 2026 as "a new era for Shelly." The 3.1 series has since added a native package builder called shelly build, isolated AUR builds, split packaging, and now RLPM. In short, the project began by consuming libalpm and has spent the last three months quietly reimplementing the thing it once merely used. That is a satisfying arc, if a little frightening when the thing you are rebuild happens to be the backbone of your OS.

There is also why this reaches beyond hobbyist circles. CachyOS, the performance-flavored Arch-based distro, made Shelly its default graphical package manager in its April 2026 release, replacing the older Octopi front-end. That put Shelly in front of hundreds of thousands of users who get it out of the box rather than installing it on purpose. RLPM's maturation is not an academic exercise for that crowd.

The skepticism has not gone away, though. On Hacker News and in the r/archlinux comments, users still note that Arch does not officially recommend Shelly as a primary system package manager. It is a fair caveat. Shelly remains a third-party front-end running its own engine, and that "recovery is not rollback" warning is exactly the kind of sentence you want to read before the moment it applies to you.

3.1.7 also introduces configurable distribution path profiles, letting Shelly point at Arch's conventional locations or Devario's own Shelly-owned ones. The native config, the package database, the cache, and the keyring all shift between the /etc/pacman.* paths and the corresponding /etc/shelly.* paths, while backend selection and path configuration stay deliberately independent, an RLPM-only build can still use Arch paths, and choosing the Devario profile does not auto-migrate an existing database. Split packaging then moves Shelly itself into shelly, shelly-cli, shelly-flatpak-backend, and shelly-notify, with a shelly-notify-none option for those who want no tray service. Isolated AUR builds gain a --isolated flag that hands each package base its own build root plus a versioned JSON plan to check against, and the native builder picks up dynamic versions, SRCINFO generation, and compression presets. The desktop side got an Atoll-backed scan in the GTK preview, wider accessibility labels, and a cleanup command that nukess the whole user Shelly cache after a confirmation.

Where it stands

Install paths depend on what you run. CachyOS users can grab it with sudo pacman -S shelly. On Arch it sits in the AUR via yay or paru, or you can clone the repo and run makepkg -si. The new backend switch lives in shelly config set NativePackageBackend rlpm, or libalpm if you want to keep the old behavior, and there is a zig build -Dlibalpm=false route for an RLPM-only CLI build.

Head here to the GitHub release announcement.