There is a hole in image-based desktops where developer tools should be. Flatpak covers apps; it does not cover strace, ripgrep or qemu, tools that exist to see and touch everything on the machine and break the moment a sandbox gets between them. A GNOME OS developer’s answer, published today, is Toolpak: developer utilities distributed as signed, verity-checked disk images, mounted in a namespace and prepended to your PATH.
Why the existing routes do not fit
The post walks through each of them and is specific about the failure. rpm-ostree overlays can break the system in unexpected ways or stop it from updating, which is why the next Silverblue is getting away from the approach. GNOME OS’s own developer extension is a fixed list of tools for building the OS, and a fixed list cannot cover the long tail. Toolbox and Distrobox replicate the old package experience inside a container that none of these tools expect to run in. Homebrew has to priority-override system binaries to work, so installing one tool can swap the library the rest of the system runs on. Flatpak is built around portals for desktop apps, and debugging utilities and IDEs are the apps that least fit that model.
The shape of the proposal
Tools ship as Discoverable Disk Images, the UAPI specification built on Verity, which gives integrity checking and a base for reproducible builds. Each tool runs in a mount namespace with the Flatpak-style /usr and /app split: /usr comes from a shared runtime image, /app holds the tool itself. The only host-side piece is a shim on your PATH that sets up the namespace and executes the real binary from the image, so the linker and system libraries are never touched. Tools do not depend on other tools; each bundles its dependencies.
Tools keep complete, arbitrary access to the rest of the system, because that is the point. The guardrail sits on the distribution side instead: install from a flagship store, signed with a trusted key, verity-checked at runtime, reviewed before listing. Apps that work fine under Flatpak are out of scope by design. The build story is meant to match: reproducible by default, content-addressed caching of build artifacts, licensing and SBOM handled at build time, with a Buildstream plugin or wrapper covering it.
Where it stands
This is a Prototypefund project with concrete work towards a prototype under way, and more promised in the coming weeks. Feedback goes through the GNOME OS Matrix room or the post. Nothing ships yet.
My read
The honest move is the one it makes early: these tools exist to see the whole system, and no sandbox is going to let them. Toolpak stops pretending otherwise and puts the trust in a reviewed, signed store instead. Whether a store can carry that weight is the argument to have; it is at least the right one.
Source: Introducing Toolpak on GNOME Blogs.