Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

docs: Extend rpm-ostree relationship a bit #249

Merged
merged 1 commit into from
Jan 5, 2024
Merged

docs: Extend rpm-ostree relationship a bit #249

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
33 changes: 25 additions & 8 deletions docs/relationship.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -38,16 +38,25 @@ Perhaps in the future we may actually support some kind of `Pod` analogue for re

## Relationship with rpm-ostree

Today rpm-ostree directly links to `ostree-rs-ext`, and hence
gains all the same container functionality. This will likely
continue. For example, with rpm-ostree (or, perhaps re-framed as
Today both bootc and rpm-ostree use the [ostree project](https://github.com/ostreedev/ostree-rs-ext)
as a backing model. Hence, when using a container source,
`rpm-ostree upgrade` and `bootc upgrade` are effectively equivalent;
you can use either command.

However with rpm-ostree (or, perhaps re-framed as
"dnf image"), it will continue to work to e.g. `dnf install`
(i.e. `rpm-ostree install`) on the *client side* system. However, `bootc upgrade` would
(should) then error out as it will not understand how to upgrade
the system.
(i.e. `rpm-ostree install`) on the *client side* system.
In addition there are other client-side mutation commands such as
`rpm-ostree initramfs --enable`.

However, as soon as you mutate the system in this way, `bootc upgrade`
will error out as it will not understand how to upgrade
cgwalters marked this conversation as resolved.
Show resolved Hide resolved
the system. The bootc project currently takes a relatively
hard stance that system state should come from a container image.

rpm-ostree also has significant other features such as
`rpm-ostree kargs` etc.
The way kernel argument work also uses ostree on the backend
in both cases, so using e.g. `rpm-ostree kargs` will also work
on a system updating via bootc.
Comment on lines +57 to +59
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not fully understanding what is being said here...it seems to conflict with what was previously said about client-side mutation. We want users to define kargs as part of the container image, correct?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Most of the time, yes. But there are also valid use cases for machine-specific kernel arguments, so that continues to work.


Overall, rpm-ostree is used in several important projects
and will continue to be maintained for many years to come.
Expand All @@ -65,6 +74,14 @@ Further, bootc does aim to [include some of the functionality of zincati](https:
But all this said: *It will be supported to use both bootc and rpm-ostree together*; they are not exclusive.
For example, `bootc status` at least will still function even if packages are layered.

### Future bootc <-> podman binding

All the above said, it is likely that at some point bootc will switch to [hard binding with podman](https://github.com/containers/bootc/pull/215).
This will reduce the role of ostree, and hence break compatibilty with rpm-ostree.
When such work lands, we will still support at least a "one way" transition from an
ostree backend. But once this happens there are no plans to teach rpm-ostree
to use podman too.

## Relationship with Fedora CoreOS (and Silverblue, etc.)

Per above, it is a toplevel goal to support a seamless, transactional update from existing OSTree based systems, which includes these Fedora derivatives.
Expand Down