1549613a7f
Move all references to the previous docs site to the new variable. Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
1.9 KiB
bootc
The main focus of {projname} is on {bootc-upstream}[bootc]. However, the "full" base image currently includes rpm-ostree which shares a lot of the same underlying code from the ostree project.
Using rpm-ostree
It is supported to install and use rpm-ostree on a {projname} system, because the bootc and rpm-ostree projects share significant underlying code.
Using in container builds
At the current time, operations such as RUN rpm-ostree install foo when
executed as part of a container build are not substantially different
from what happens with RUN dnf install foo - the two codebases
ultimately share a lot via libdnf.
There’s not generally a strong reason to use rpm-ostree inside a container
build.
Client side operations
rpm-ostree upgrade/rollback
The rpm-ostree upgrade, rebase, deploy verbs etc. will all gracefully
interact with a bootc system - at the current time they operate on shared state.
You can interchange rpm-ostree upgrade with bootc upgrade, etc; they
currently perform the same operations in general.
rpm-ostree install/override replace
However, any local state mutations such as package layering, removals, or
enabling e.g. rpm-ostree initramfs --enable will cause bootc upgrade
to error out.
Hence if you choose to use such features, then you will need to switch over to interacting with rpm-ostree going forward for updates.
In the more medium term, there are plans to extend dnf to also support
client-side functionality similar to this:
client side layering tracker.
This would build on more generic support for {bootc-upstream}/booting-local-builds.html[booting local builds] for persistent layering.