Re: F36 Change: ostree native containers / CoreOS layering (System-Wide Change proposal)
On Wed, Nov 24, 2021, at 1:26 AM, Robin Lee wrote:
This function is unrelated to 'rpm' but unfortunately provided by
'rpm-ostree'.
Maybe we should provide another standalone tool so non-rpm/dnf-based
distributions can be easier to deploy.
No, all the "ostree-container" logic lives in
https://github.com/ostreedev/ostree-rs-ext/
which as with the rest of ostree (and like podman/docker), has no dependency on
rpm/dpkg/whatever and never will. You can put whatever you want in it and build however
you want.
If you look at the PR to rpm-ostree which added this functionality (this all exists today
btw!)
https://github.com/coreos/rpm-ostree/pull/3139/files#diff-2e9d962a0832160...
you can see how rpm-ostree just picked up the ostree-ext changes as a library.
(While this is only somewhat related to your point, I think it is very interesting and
important to note that a big part of this proposal is that we now easily expose the
ability to inject non-RPM content into derived images and boot and upgrade them via
rpm-ostree, so that's a "less RPM involved" angle)
ostree-ext also exposes a CLI, but see also
https://github.com/ostreedev/ostree/issues/2480
That said, it is certainly true that ostree is more of a low level library and most of our
effort is on rpm-ostree. Eventually perhaps it may make sense to have at least a polished
shared CLI/daemon code upstream in ostree that gets shared more across distributions, but
there's nontrivial logistical/political/technical aspects to that. It's perhaps
somewhat analogous to librpm versus dnf/zypper.
Also omitted from this is that my job also involves making all this work really well in
OpenShift/Kubernetes in addition to this change (which is basically just talking about
"single node"/"baseos" functionality that applies to non-Kubernetes
Fedora cases too). So juggling those two has taken most of my personal time versus
polishing the "ostree but not rpm-ostree" case.