Will bootc completely replace rpm-ostree or will the work in conjunction?
Is bootc built in such a way that it can work with version controlled systems like rpm-ostree as with A/B systems like systemd-sysupdate?
In rpm-ostree you add a package to the system by layering. Will this replaced by a local containerfile in which you add the package to be installed? In the latter, the system has to be build locally. I guess this is not desirable because it takes a lot of time?
I read that several tools will be integrated in dnf. Will we use dnf commands in the future instead of bootc and rpm-ostree?
And to be sure: with bootc the container image is converted to a (local) disk image so no virtualisation is necessary? Podman-bootc is only used for testing the image/container?
Does bootc download the complete new version of the operating system or does it download some kind of delta file? Or does it download a new layer (but to be honest, I donāt know what a layer really means in this case).
Iām not a Fedora dev, but Iāve been asking similar questions as you. Hereās what Iāve been able to gather:
rpm-ostree will be replaced by bootc and dnf5 for the most part eventually I think. bootc to manage the container management tasks. And dnf5 to manage package layering. Though for now dnf5 doesnāt do layering and bootc canāt manage the containers if there are any packages layered. So rpm-ostree will be needed until these kind of things are worked out.
I donāt think it would take a lot of time. You can basically do this locally by creating a Containerfile with a RUN dnf install foo, and build the container. It should basically take the same time as running the dnf command.
The containers are able to be divided up into chunks and so only the necessary ones are downloaded. So though this reduces the size compared to needing to download the entire container image, I think it still uses more data than the current rpm-ostree upgrade on non-container atomic systems.
$sudo bootc upgrade
layers already present: 43; layers needed: 22 (1.2 GB)
Fetched layers: 1.13 GiB in 2 minutes (8.07 MiB/s)
Queued for next boot: quay.io/fedora-ostree-desktops/kinoite:41
Version: 41.20240923.0
Digest: sha256:39e4f04522adcae099caffcea28fd51ce12c78af2ccb5e47d2e6baafa8303626
Total new layers: 65 Size: 2.8 GB
Removed layers: 22 Size: 1.2 GB
Added layers: 22 Size: 1.2 GB
Iām also not a Fedora developer, although I have some contributions to the project.
Here are some additions to the answers from the previous post.
Iām not sure what you mean by ā(local) disk imageā, but to run a container native (bootc) Fedora OS youāll most likely need to convert a bootable container into a so-called disk image, such as ISO, raw or qcow2 to provision a new system. You can convert a bootable container into a disk image with the bootc-image-builder which itself needs to be executed inside a container. podman-bootc allows you to easily run a local bootc image in a VM and get shell access to it. Under the hood, podman-bootc uses bootc-image-builder to create a disk image that is subsequently used to create and boot a VM.
Yes, with a disk image I indeed meant a disk image like iso, raw or qcow2.
āwhich itself needs to be executed inside a containerā
Sorry, I donāt completely understand what you mean: do you mean that bootc-image-builder runs in itās own container, or do you mean that it needs to be run in the container that is being downloaded during an upgrade?
I have one more question:
Will it be possible with bootc to overlay packages and if so, how?
Will it be something like dnf install [application name] or will the user have to modify a local container file? I guess the first solution is preferable. How will it work in the background? Is this already determined or not? And I guess it will still be needed to reboot the system after the installation of the new package? Will this all work in Fedora 42?
No, the bootc install command installs the running container to a target.
This has already been basically answered in a previous post.
The bootc and rpm-ostree projects share a significant code base.
Currently, for Fedora CoreOS and Fedora Atomic Desktops, local package layering support is achieved via rpm-ostree. In the longer term, there are plans to extend dnf to support client-side functionality as well.
A top-level goal of bootc is to encourage a default model where Linux systems are built and delivered as (container) images.
Not yet.
Right now, the rpm-ostree install --apply-live command will perform a subsequent apply-live operation to apply changes to the booted deployment. I am not sure if this functionality will be implemented in dnf if such an approach is chosen.
Thereās still a lot of work to do, so Iām not sure.
As the underlying concept is completely different to a package based variant, the flow differs significantly but lets put the focus at result.
Here is a POC
that allows to install packages (transiently) and it generates locally an image the gets staged and booted then (package persistence). So, under the hood quite āexpensiveā but possible.
IIRC, this is what DNF5 should do in the future, but let others that work on this explain this in more detail.