Future between bootc and OSTree

[antheas]

So I spent the last 1-2 weeks looking into the rpm-ostree, built my own Fedora based ostree image using tree files, and rebased between it and a variety of ublue images around 30 times. This is as part of testing in optimizing Bazzite's update process (with some relevant findings that are not part of this issue) but I also caught a bit of the atomic bug.

In any case, the topic of this issue is getting some understanding between the future relationship of OSTree and bootc.

The documentation mentions that OSTree is an implementation detail of bootc. And perhaps for end users it is.

However, the backend plays a large role for the base image builder/OS maintainers, as it affects the following:

• bootloader (both stanzas and options)
• kernel configuration
  • Multiple kernels anyone?
• the performance characteristics of the final image
  • e.g., overlayfs vs OSTree have inverse performance characteristics as layer number increases
• Live ISO configuration (which is something I want to look into)
  • An OSTree Live ISO can deploy its OSTree to the target system (theoretically)
  • A container based ISO that boots a container can deploy that container
  • An OSTree based bootc ISO cannot deploy the OSTree and does not have space to deploy a container
• On a certain level, building the image itself (although this should change soon ?)

Therefore, it would be nice to know what the future of OSTree itself as a backend is, before investing time and resources into it.

Is there a plan for transitioning into an overlayfs podman based backend?

If yes, are there performance benefits to it? What is the timeline? 1 year, 2 years, 3 years?

Are there downsides? Nested whiteouts, kernel instability, runtime performance degradation?

If not, that is good for OSTree, and in that case, how is the podman integration looking? In order for the "build your OCI image" to become a thing, especially for layering packages, running RUN yay -S <mypackage> should be faster or just as fast as deploying an OSTree repo, running yay -S <mypackage> under a chroot with a local cache, and deploying the result. While not duplicating storage (#512). Otherwise, the latter will be preferred.