Shelly 3.1.9 puts "in-place file migration" behind its own native package engine
Shelly, the GTK4 package manager for Arch Linux, released v3.1.9 on today, and its headline feature only kicks in if you've actually switched to the project's from-scratch engine. The update introduces what Shelly dubs "in-place file migration" for RLPM, a package manager written natively in Zig. It lets a fresh package take ownership of files already sitting on your system without overwriting what's inside them.
That distinction matters most when one package replaces another. Otherwise it's a niche nicety you may never notice.
Shelly's own migration guide frames the problem plainly. When an installer or a one-off setup step drops a file onto your machine, that file never belongs to any package. If a new package now "should" own it, installing either clobbers the existing content or strands the file, unmanaged. The old trick was .pacnew and .pacsave files that nag you to merge by hand. RLPM 3.1.9 just quietly adopts the file and moves on.
There are guardrails here, though. The adopted path must be an exact, canonical, root-relative path. No wildcards. No recursive directory adoption. No renaming or copying, either. RLPM takes the object, its bytes, and its attributes, then records the incoming package as the new owner.
Head here to the migration guide if you want the JSON schema in full, but the gist is a new shelly_migrate array in a PKGBUILD. Each entry is a JSON object with a required path and from field, plus optional optional and backup flags. Validation is strict, and the repo explicitly warns packagers to use shelly_migrate rather than hand-rolling raw xdata.
One thing worth flagging: if you're running the default libalpm backend instead of RLPM, this feature isn't for you. Shelly rejects archives that declare migration semantics on that backend entirely, so it lives only on 3.1.9+ with RLPM.
A native engine, three weeks old
RLPM only reached full native-package maturity in v3.1.7, released 16 October 2026, just three weeks before this update. By my count that's arguably the most significant release in Shelly's short history. It reimplemented repository reading, dependency resolution, archive verification, preflight, hooks, payload execution, and database publishing all in Zig, instead of leaning on libalpm the whole time.
The engineering detail here is substantial. SQLite repository databases get read in memory without ever touching disk, archives are copied into a sealed in-memory file before GPG and checksum verification, and hooks run in an isolated network namespace by default. There's even root-relative confinement via Linux openat2 to keep symlink path traversal at bay.
Shelly is candid that complete libalpm compatibility remains unfinished. RLPM aims for interoperability, not certified parity. So this migration contract, tightly coupled to the Devario distribution, is one more step down that road rather than the destination.
For Devario specifically, 3.1.9 adds automatic adoption. Rather than per-file declarations, it discovers unowned files an incoming package also supplies, toggled by an AutoMigrateUnowned setting in /etc/shelly.conf. Devario's path profile flips this to true; the pacman profile and standalone RLPM owners default to false.
A project chasing a complete desktop stack
Shelly doesn't float in isolation. It's the package-management keystone for Seafoam Labs, which is also building an independent Arch-derived distribution called Devario, along with the Aqueous compositor, the Pearl desktop, a dependency viewer called Starfish, and a disk-mount manager called Pori. The Devario-specific behavior in 3.1.9 makes sense in that light. The automatic adoption half is what lets Devario itself upgrade across package replacements without stranding custom GPU-helper scripts or local config.
The team is small, and Seafoam Labs talks about craft: "performant code, good design, and making things that actually feel nice to use." Zoey Bauer, a co-founder and .NET architect, is Shelly's primary maintainer and she released 3.1.9. She's also the one who publicly answered a pushback on the UI toolkit. When 9to5Linux's Marcus Nestor's readers floated Qt6 as an alternative, Bauer said she deliberately chose "GTK WITHOUT libadwaita because I like the way GTK looks," wanting users free to theme it however they wanted.
Head here to the GitHub release notes.
