What is the recommended way to manage "pet" containers on Silverblue?

Project Discussion
1

As far as I understand, there are 3 main ways to install new apps in Silverblue:

  • Layered Packages
  • Flatpaks
  • Toolbx

I want to install a CLI app into a container. The app is packaged in rpm and found in the stable Fedora repos.

  • Because it’s a container, I rule out the rpm-ostree layered packages.
  • I cannot find any flatpak on flathub or the Fedora flatpaks
  • I have been creating Toolboxes and dnf installing the rpms in them. The issue is that these toolboxes require manual maintenance (updates) and there isn’t a way to rebuild the container rapidly (aka no Dockerfiles).

I have been wondering if the solution isn’t to create Dockerfiles and manage them directly from podman, but there are some things that put me off:

  • It’s an extra way of managing packages, so it adds complexity.
  • I want to make sure I’m reusing the same layered images as the ones already used by Flatpak
  • Managing the interaction between the host and the container can be tricky and error prone.

Another thing I’m thinking about is maybe creating my own Flatpaks and either push them on Flathub or maybe host them locally?

I’m sorry if I’m asking too many things at once, or if I’m a bit unstructured. I am specifically looking for recommendations on how to install apps on my laptop when they’re not in Flathub.

2

Re: maintaining Pet Containers
I’m using Distrobox (Toolbx equivalent). I set up a cron job to update my containers unattended once a week. Arch, Ubuntu, Fedora; they’re all updated weekly. When things break, I don’t know why, but when they don’t it’s stressless

3

@papiris thanks.

  • Does it mean that you install multiple apps per distrobox?
  • How do you deal with breakage?
  • How do you deal with major version upgrades of the base image (F35->F36)
4

Note you can derive from the Toolbox image and add the things you want. IMO, that workflow should be more emphasized in docs and maybe even CLI. Here’s an example repo that does this and has a GitHub Action to rebuild weekly.

2 Likes
5
  1. yes, since I use many graphical apps in my distroboxes it would be a pain to have a graphical environment installed in each one. So I have one box for each distro, and try to avoid package conflicts.
  2. Pretty poorly tbh. I’m no docker wizard, and I don’t know how to create a reproducible container image with the packages I need, so I treat the container as a regular linux system wrt breakage.
  3. Thanks for reminding me, I hadn’t upgraded my Fedora container to version 36. Used dnf distro-sync, took 2 minutes.
6

I avoid Toolbox at all costs, as it has design flaws that they refuse to change. Different containers pollute each other with their resources, which defeats the purpose of using them to isolate different projects. See: Adjust home path · Issue #348 · containers/toolbox · GitHub

I highly recommend using Distrobox instead.

7

@ Ddde9ddf6f: I’m not interested in a Distrobox vs Toolbox discussion right here. My question still stands, even for Distrobox. How do you manage the lifecycle of long-lasting containers?

@jlebon: I’m interested, can you tell me more about how making my own image can help me? Thanks a lot :slight_smile: