From Fedora Project Wiki

< Changes

Revision as of 13:44, 19 April 2023 by Rishi (talk | contribs) (Write some benefits)


Make Toolbx a release artifact and have blocking test criteria

Important.png
This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

Summary

Up to date fedora-toolbox OCI images should be published on registry.fedoraproject.org as a release artifact, just like the installation ISOs for the Editions from download.fedoraproject.org, and there should be release blocking test criteria to ensure a usable toolbox RPM.

Owner

Current status

  • Targeted release: Fedora Linux 39
  • Last updated: 2023-04-19
  • FESCo issue: <will be assigned by the Wrangler>
  • Tracker bug: <will be assigned by the Wrangler>
  • Release notes tracker: <will be assigned by the Wrangler>

Detailed Description

Feedback

Benefit to Fedora

This improves the quality of containerized Toolbx environments on Fedora by adding formal requirements to ensure that they are usable when a new Fedora is released. This will bring them closer to the reliability of interactive command line environments running directly on the host operating system.

Toolbx is a popular tool in Fedora, which allows the use of interactive CLI environments for software development and troubleshooting the host OS, without having to install software on the host. It is built on top of Podman and other standard container technologies from OCI.

Toolbx is installed by default on CoreOS, Silverblue and Workstation. It is indispensable for software developers using Silverblue to bypass the difficulty of setting up a development environment in the usual way. It is widely used, even on Workstation, by those who don't want to pollute their host OS, or want to access a CLI environment that's different from the host's without installing a virtual machine, or want a pre-configured development environment.

Currently, there is no formal requirement for Toolbx to be usable when a new Fedora is released. For a tool that's so popular and provides something as fundamental as an interactive CLI environment, this is worth addressing and this Change aimsms to do so.

Toolbx has two parts — an OCI image, which defaults to fedora-toolbox on Fedora, and the toolbox RPM. The OCI image is pulled by the RPM to set up an interactive CLI environment within a container. Toolbox environments have seamless access to the user’s home directory, the Wayland and X11 sockets, networking (including Avahi), removable devices (like USB sticks), systemd journal, SSH agent, D-Bus, ulimits, /dev and the udev database, etc..

First, we want to ensure that there are up to date fedora-toolbox OCI images published on registry.fedoraproject.org as a release artifact at critical points in the development schedule, just like the installation ISOs for the Editions from download.fedoraproject.org. This should at least happen when an upcoming Fedora release is branched from Rawhide, at Beta and final GA. If possible, it would be good to have them updated more frequently as part of the usual compose.

This is important because Fedora's OCI infrastructure is often broken. Here are two recent examples of fedpkg container-build not working. In the second case, it was preventing the images from being rebuilt to pull in an important bug-fix. The branching of an upcoming Fedora release from Rawhide is a particularly chaotic time. Since the fedora-toolbox images for Fedora Branched and Rawhide are not rebuilt as part of the branching process, there is a lot of confusion for end-users until someone manually rebuilds the images and gets them published.

Scope

  • Proposal owners:
  • Other developers:
  • Policies and guidelines: N/A (not needed for this Change)
  • Trademark approval: N/A (not needed for this Change)
  • Alignment with Community Initiatives:

Upgrade/compatibility impact

How To Test

User Experience

Dependencies

Contingency Plan

  • Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
  • Contingency deadline: N/A (not a System Wide Change)
  • Blocks release? No


Documentation

N/A (not a System Wide Change)

Release Notes