Why replace ostree with bootc? Doesn't ostree do it's job well?

[pramodvu1502 (Pramod V. U.)]

Recently, with future versions of fedora atomic desktops, there have been plans to replace the current [rpm-]ostree system with bootc, and a modified dnf.

OStree supports container booting, and works well… rpm-ostree, while lacking at non-rpm installations, supports rpm natively very well… [most of them]… [not supporting arbitrary untracked files is good for immutability]

I see in many issues that bootc doesn’t support this, that, multiple kernels, etc… and “needs work”.

And I also have seen discussion on a github issue on installing packages on bootc, by modifying a containerfile somewhere in /etc, to have RUN dnf install -y $PACKAGES…

I am also seeing how many features already in ostree need to be implemented in bootc, and how bootc is needed because ostree doesn’t support a trivially implementable change.

And the composefs, which seems very complicated just to prevent a read-write remount of the immutable /usr [Can’t SELinux do it? Will users actually go such great lengths just to break their system? ostree admin unlock provides a clean way to do that anyways… but oh! bootc]
And to prevent corruption and fsck runs… [is it really such a big problem? After all, ostree supports rollbacks in case of such an event]

All of the above is just my viewpoint, I might have missed or not known something…

So does someone know the motive for all this?

Some links:

Questions about bootc and rpm-ostree

Hello Everybody, 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? Thanks in advance …

Here bootc needs to have some features ostre already has…

Local package layering story with bootc & dnf5 (#4) · Issues · fedora /...

Implementing features already in ostree in a “bootc-only world” without ostree…

Bootc in Fedora Silverblue

I noticed that bootc was part of my last Silverblue update. What does this mean for the system? Is the way it boots actually changing, and is there anything I need to know about new or different functionality?

bootc is limited so for now ostree, but eventually it will gain those features and replace ostree

[pramodvu1502 (Pramod V. U.)]

@steppybug

Have you looked at Colin Walters work on rpm-ostree, ostree, osbuild etc. in fedora, opencontainers, and other places? The whole story would fill a book! And there are many others who have contributed.

Yes, so what is the issue?

@steppybug

I have been following bootc stuff since it’s earliest days. A main developer of rpm-ostree and bootc makes convincing arguments as why rpm-ostree needs to be abandoned in favor of bootc. The bootc work is not there yet but much progress has been made.

What are the arguments? Where can I read them?

@steppybug

In a fedora discussion topic the answer is simply: bootc is better.

“Discussion” is in “Fedora Discussion”…
WHY is bootc better?

[miabbott (Micah Abbott)]

@pramodvu1502

WHY is bootc better?

In my opinion, how you feel about this question will be aligned with your thoughts on using containers for building/shipping applications and/or an OS.

bootc was designed from the ground up to be fully container native; the premise is to leverage the existing container ecosystem to build and distribute operating systems. Currently, the backing filesystem transported in the filesystem is ostree based, but that could be changed in the future (and likely will).

If you are not sold on the idea of using container images as the build/delivery mechanism, you may not feel that bootc is better. You pointed out a number of features currently missing from bootc and as such, you have an argument that it is not a complete replacement.

Personally, I think there is a lot of value in adopting the container-native approach for building/distributing an OS in a container image. The breadth of the container ecosystem allows you to tap into the same solutions that you have used for building/distributing applications as container images, such as robust CI/CD pipelines, vulnerability scanning, container image signing, etc. Additionally, the language of building containers via Containerfiles is very well understood and provides an easy entrypoint for many people looking to experiment with building an OS in a container image. While ostree has had some great success, it did not produce the same broad ecosystem and resulted in many users inventing their own bespoke solutions that were not easily adopted by multiple users.

Finally, while ostree will remain well supported for quite some time, the focus and efforts of the core rpm-ostree team are shifting towards bootc. Continuing to invest in and advocate for a technology that will be replaced by bootc does not feel like a good position to be in.

[pramodvu1502 (Pramod V. U.)]

I agree. Now I understand.
Thanks.