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?
!