Community maintained images for toolbox (and distrobox)

In this post I will discuss how we made community maintained container images for common Linux distributions available for use with toolbox (and distrobox) and why we can not call them “official”.

What is toolbox (or toolbx)?

But first, let’s start with a bit of context. On image based Linux distributions (such as Fedora Silverblue, Fedora Kinoite, Fedora CoreOS, etc.), it is not practical to install random packages the way you may be used to do on classic package based Linux distributions. You are expected to run applications in containers, either via Flatpak for graphical applications, or via podman for command line ones.

While you can directly manage your own custom container images and environment configurations, it is not useful to have everyone rediscover what to do thus a new tool has been created to make that easier: toolbox (or toolbx) (containers/toolbox on GitHub).

Toolbox lets you easily create a mutable and persistent environments inside containers that are well integrated with your host system.

Why do we need other images?

Toolbox needs a few things to be available in the container image to be able to provide a good user experience and integration with the host system (see details in the Distro support page).

The current version of toolbox only primarily includes support for a Fedora based environment via the fedora-toolbox container image that includes all the required tools. There is also a RHEL 8 image based on UBI available.

If you wanted to use toolbox with another Linux distribution, you had to make your own custom container image and to make sure to include all the required tools.

Introducing toolbx-images

Together with some other folks from the community, we have setup a community maintained repository so that we can share the maintenance of container images designed to be used with toolbox.

The toolbx-images repository is hosted on GitHub and the container images are hosted in the quay.io/toolbx-images org on Quay.io. The full instructions on how to use them are available in the README. The images are rebuilt and updated weekly (at minimum). Everything is public and open on GitHub: the image builds happen via GitHub Action runs.

We now have images for AlmaLinux, Alpine Linux, Arch Linux, CentOS Stream, Debian, openSUSE, RHEL, Rocky Linux and Ubuntu. It’s also really easy to add more.

See also toolbox#1019 for historical details.

What about distrobox?

Distrobox is another tool very similar to toolbox. One of its advantage is that it can directly use any Linux distribution container image as a base. But in order to do that, it needs to setup the environment in the container the first time it is created.

Distrobox is not included in Fedora Silverblue and Fedora Kinoite by default but you can easily install it either by overlaying the RPM package with rpm-ostree (rpm-ostree install distrobox) or by installing it manually in you home directory via the official instructions.

You should be able to directly use the same container images that we are making for toolbox with distrobox to reduce the setup time for each newly created container created. I’ve started a discussion about that in distrobox#544.

Why are those images not official?

To answer that question, we have to answer another one: What makes a container image official?

According to me, a container image is official if it is provided directly by the Linux distribution it is based on, maintained by developers or users of that Linux distribution and hosted on infrastructure validated by that Linux distribution.

Right now, as far as I know, only Fedora is building, maintaining and distributing a container image purposely made for toolbox so there is only one official image.

If you want to have an official image for toolbox for your Linux distribution, then please reach out to your maintainers or developers and suggest or contribute the necessary work.

Conclusion

In the meantime, feel free to join us and help us provide as many community maintained images as possible.