Using dnf

A key toplevel goal of this project is to support and encourage creating custom derived container images, using every tool and technique that applies to "application" containers.

Many examples use RUN dnf install. There is nothing special about the use of dnf in a bootc-derived container versus an application container; it is exactly the same code.

The system is mounted read-only when "deployed" as a physical or virtual machine.

At the current time, depending on the version, dnf install for example may appear to start working, but will error out with e.g.

error: can’t create transaction lock on /usr/share/rpm/.rpm.lock (Read-only file system)

This is a known bug; see e.g. this PR.

At the current time, rpm-ostree is also included in the base image, though this may change in a future version. For more, see rpm-ostree.

Conceptually, it would be possible to extend the tooling that surrounds fedora-bootc to also enable a model where this would work:

And then pass that to e.g. Anaconda to write to disk.

In this theoretical model, there wouldn’t be bootc in the deployed image, and updates could be done by dnf directly.

The core disadvantages of this would be:

At the current time such a model is not within the direct focus of this project.

However, technically this would only be a small extension of the existing Anaconda support for deploying a raw tarball, and if someone was interested in working on it, it could be added to the overall Fedora/CentOS container-related project scope.