Toolpak wants to do for developer tools what Flatpak did for apps
On 26 September 2026, GNOME developer Jordan Petridis introduced Toolpak, a Flatpak-inspired format for shipping strace, ripgrep, and qemu on image-based systems without breaking them. For anyone working on Silverblue or GNOME OS, it fills the gap immutable distributions never closed.
26 September 2026. GNOME developer Jordan Petridis publishes a post titled “Introducing Toolpak”, laying out a distribution format for developer tools built for image-based systems. 26 September 2026. The proposal is picked up the same day by Phoronix, which describes it as “a Flatpak for tools”. Coming weeks. A prototype is expected as part of a Prototypefund project. Why it matters: Flatpak solved app distribution on immutable distributions but left a gaping hole for command-line tools — and that is exactly the hole Toolpak aims to fill.
The gap Flatpak never closed
Mainstream operating systems — iOS, Android, macOS, ChromeOS — moved years ago to image-based architectures: the system is a signed, atomic block you do not mutate file by file. The Linux desktop has started to follow, with Fedora Silverblue, GNOME OS, Vanilla OS, and openSUSE Aeon. The benefit is real: atomic updates, reliable rollbacks, a smaller attack surface.
Flatpak more or less solved distribution of graphical apps on those systems, with Flathub as the catalogue. But the developer story is still unfinished. On a conventional system, installing a tool is an apt install strace or dnf install qemu, followed by compiling against the system libraries. On an image-based system that reflex no longer works: the image is read-only, and any global overlay threatens its coherence.
Each current workaround has a known limit. rpm-ostree overlays on Silverblue can break the system in unpredictable ways — which is why the next iteration, built on bootc, explicitly avoids them. The monolithic “developer” overlay, in the style of Android or iOS, is a finite list of utilities tuned to build the OS itself, not the long tail of debugging and kernel-development tools. Toolbox and distrobox recreate the package experience inside a container, but a confined environment restricts exactly the cases where you need to inspect the host. Homebrew provides an independent toolchain but prioritises its binaries over the system’s — install QEMU and it can override the GLib the rest of the system depends on.
Flatpak itself does not fit: designed for desktop apps, it imposes portals and a sandbox that sits badly with command-line utilities, debuggers, and IDEs. Petridis is blunt: many of the utilities developers rely on “can’t realistically be run in a confined environment without a near complete rewrite”.
What Toolpak proposes
Toolpak starts from three non-negotiables: tools must be independent of the host system and not break it if they fail; they must draw on a large catalogue, as in distribution repositories; and they must work out of the box, with no porting — including when they shell out to other system tools.
The implementation Petridis sketches is precise. The image format would be Discoverable Disk Images from the UAPI.3 spec, opening the door to Verity and reproducible builds. Each tool would be mounted in a dedicated mount namespace, with the /usr / /app split borrowed from Flatpak: /usr comes from a shared runtime image, /app holds the tool’s own content. Binaries would be prepended to the user’s PATH, and a launcher would set up the namespace before executing the real binary — without touching the linker or the system libraries.
Two choices structure the project. First, tools do not depend on other tools: they bundle all their dependencies, eliminating the dependency resolution that weighs down conventional distributions. Second, anything Flatpak can already package is rejected: Toolpak only handles what Flatpak cannot do.
Why it is safer than a global apt install
The point that matters to an SRE or a fleet administrator: Toolpak inverts the trust hierarchy of a traditional apt install. Installing a global package means giving a repository the power to write anywhere on the system. A Toolpak never mutates the base image; it overlays a single binary at a single point of the PATH, and nothing else.
Security is built in from the start. Images will have to be signed by a trusted key, Verity-checked at runtime, and reviewed before appearing in the flagship store. The stated goal is to kill the “download a static binary and chmod +x it” reflex in favour of verifiable distribution, on the Flathub model.
The trade-off is explicit: because a Toolpak has complete access to the system, trust moves from the repository to signature and review. It is the same compromise as Flathub, applied to a class of tools nobody had covered yet. The target build chain — build orchestration, content-addressable storage caching, reproducibility by default, licence and SBOM handling, a Buildstream plugin — answers the traceability a platform team demands.
The shift in ergonomics is worth spelling out. Today, getting strace onto an immutable system means either a persistent rpm-ostree install overlay that risks the image, or a container that hides the host. The Toolpak vision replaces both with a single signed, verifiable image dropped into a mount namespace — conceptually one command, like toolpak install strace, with the same trust model as installing an app from Flathub. That is a small change in syntax and a large one in what an atomic desktop can promise its developers.
The atomic-distribution shift
Toolpak lands in the middle of a broader acceleration. Fedora is preparing to move Silverblue to bootc, dropping the rpm-ostree overlay paradigm in favour of composed images. GNOME OS is experimenting with sysupdate and composefs for updates. Vanilla OS and openSUSE Aeon push equivalent models. All of them hit the same wall: graphical apps are solved by Flatpak, but the developer tool remains a blind spot.
That gap explains the proliferation of workarounds. Some developers run a conventional distribution in a VM or container just to keep strace and gdb within reach. Others layer overlays they know are fragile. Each workaround reintroduces exactly the complexity the atomic image was meant to remove.
Toolpak is one more answer to this problem, but with a twist: it accepts not to confine. Where Flatpak and containers start from “everything must be sandboxed”, Petridis starts from the opposite observation — some tools, like strace inspecting the kernel through ptrace, cannot be confined without losing their purpose. Signature and review then replace the sandbox as the mechanism of trust.
Verdict
If you develop on an image-based distribution — Silverblue, GNOME OS, Aeon — Toolpak is still a proposal with a prototype to come; until then, keep Toolbox or distrobox for disposable environments and avoid persistent rpm-ostree overlays for anything non-critical. If you maintain command-line tools, watch for Petridis’ call for help on Matrix (#gnome-os:gnome.org): being among the first packagers of the future catalogue is real distribution leverage. If you run a fleet of Linux workstations, take the deeper lesson — developer-tool distribution is the next immutability frontier, and the systems that solve it without breaking the image will win engineering teams. Flatpak did the job for apps; Toolpak wants to do it for tools, and it is a piece that has been missing since the Linux desktop went atomic. Watch the prototype closely: if it ships with the signing and review story intact, it will be the first serious answer to a problem every atomic distribution has been dodging.