Provide an rpm-ostree compatible interface to help with migration

[travier]

We have a lot of existing systems using rpm-ostree that we would like to migrate to bootc in the future (Fedora CoreOS, IoT, Atomic Desktops).

But bootc currently does not provide the same capabilities as rpm-ostree does today so we have to keep both in the images.

This is confusing for users as they either have to learn both tools and their limits or stick to rpm-ostree, which slows down the transition.

To help with the adoption and deprecation of rpm-ostree, we could add an rpm-ostree compatible interface to bootc (a subset of rpm-ostree's DBus interface and command line tool interface) for the most important parts of rpm-ostree that are used today by applications such as Zincati, GNOME Software, Plasma Discover and the MCO.

This should make it easier for us to migrate all rpm-ostree based variants and remove rpm-ostree from the image while letting us freely innovate on improved interfaces for bootc.

This is an alternative to #347 (calling rpm-ostree from bootc).

This would help with:

• Roadmap to Fedora Bootable Containers coreos/fedora-coreos-tracker#1726
• https://gitlab.com/fedora/ostree/sig/-/issues/26
• Making Cincinnati updates work with ostree containers coreos/fedora-coreos-tracker#1263

[cgwalters]

rpm-ostree will continue to be maintained for quite a long time; I wouldn't frame things as if it needs to be dropped soon.

A core premise though of bootc is that if we make it sufficiently compelling to build derived container images for the OS, there's just less use cases for what rpm-ostree is doing today. My instinct is that this is especially true for server cases (coreos/iot/OCP) and so I don't see a need to try to maintain a shim for those vs just porting them. Those cases don't need DBus for example.

I'd frame this more then as a desktop-specific problem and not a generic bootc problem. And I think we already have trackers for the two biggest sub-problems for the desktop case, which is an unprivileged/polkit interface (#409) as well as the package layering case in https://gitlab.com/fedora/ostree/sig/-/issues/26

There's also the side problem that rpm-ostree's DBus interface is ugly and I definitely wouldn't want to carry a new implementation of it versus just...having those cases continue to use rpm-ostree for now.

To connect multiple threads here...I think probably what the desktop case really wants is a dbus/polkit interface to something like https://gitlab.com/fedora/bootc/tracker/-/issues/4 but IMO that's way out of bootc's scope and should be owned by a different higher level project.

So closing this as I think we have this mostly covered elsewhere.