You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It'd be good to change rpm-ostree to call out to bootc instead for container operations, instead of directly talking to ostree-ext where possible; this would give us one source of truth for container code.
We'd need a stable progress API in bootc to do this.
Also this in general implies that features added to bootc are also rpm-ostree features by default; things like logically bound images.
The text was updated successfully, but these errors were encountered:
Hmm, is this basically containers/bootc#347 but flipping what drives what? Notably, the main thing that is required regardless would be to have a way for bootc to only download and import but not deploy an update.
Notably, the main thing that is required regardless would be to have a way for bootc to only download and import but not deploy an update.
Yes that and a stable progress API are the main things I can think of.
However, there's another important thing here actually...until package layering is ported, bootc can't do unified storage - or at least, would need to be forced into a mode where we still create an ostree commit.
It'd be good to change rpm-ostree to call out to bootc instead for container operations, instead of directly talking to ostree-ext where possible; this would give us one source of truth for container code.
We'd need a stable progress API in bootc to do this.
Also this in general implies that features added to bootc are also rpm-ostree features by default; things like logically bound images.
The text was updated successfully, but these errors were encountered: