When I first heard about the Steam Deck I was keen to get my hands on one, and while I cannot claim to be a gamer, I do have a few games in my Steam library that I enjoy firing up on the sofa in the evenings. The Steam Deck also has a desktop mode, but as SteamOS is immutable by default, additional applications need to be installed via flatpak, which does not offer the same variety of applications as other distributions such as Ubuntu. One way around this is to use Distrobox along with a rootless podman installation.
Distrobox is essentially a (bash) wrapper around either Podman or Docker. It works a bit like a codespace, but for desktop applications. It starts arbitrary OCI container images in the background, runs a custom entry point that installs missing dependencies, and makes sure the username and id between container and host are identical. At runtime, the user’s `$HOME’ is provided and everything looks and feels as if you were running e.g. Ubuntu or Arch native. This means you can mix and match distributions to get the latest version of any application. Want to use VS Codium from Arch, but Meld from Ubuntu? No one is saying you can only use one Distrobox.
With the 1.5 release, Distrobox introduced the assemble command, which allows users to define in a single ini style config file which containers to start as Distroboxes, with the ability to run commands after creation. A recent commit takes this even further by allowing the definition of applications that should be automatically exported to the application launcher as well as the host’s $PATH.
Whenever there is a need to install an additional package, I like to use my own container images. Instead of downloading and installing the same data over and over again, I do this once during the container build and then store the result in a private container registry. This costs a bit of disk space, but speeds up the startup time in CI pipelines or devcontainers. Also, these containers themselves can be built automatically through a pipeline of their own.
To test the new $PATH export functionality, I extended the Cloudron Surfer container, which is part of my Cloudron Drone app. Now, instead of having to have a specific npm version installed on my host, I can simply add the following to my distrobox.ini file:
[surfer]
image=git.9wd.eu/felix/cloudron-surfer:distrobox
start_now=true
exported_bins="/usr/local/bin/surfer"
This gives me the ability to call surfer directly from my host’s cli. My only remaining problem is that so far I have not been able to run the same rootless podman from inside one of my distroboxes, which means that for container builds I always need to distrobox-host-exec to escape from the container back to the host.