Let's work towards getting Silverblue composes to use the new unified core mode. Upstream in rpm-ostree, we want to eventually move to unified core by default (see https://github.com/projectatomic/rpm-ostree/pull/1739), and Silverblue is one of the major users left (for completeness, there's also IOT and FAH, though both of those likely use a package set similar to FCOS and thus shouldn't encounter any issues, but to be checked... we could also just keep FAH on non-unified-core mode until it's EOL).
Roughly, this involves two major steps:
--unified-core
Can you describe or link to what the difference is - the help for rpm-ostree tree compose says:
rpm-ostree tree compose
--unified-core Use new "unified core" codepath
which isn't exactly informative :-)
I'm +1 but we should probably either wait until the f30 release or make it configurable in the pungi configs so we can easily switch it on/off (i.e. turn it on for rawhide and not for others)
I just put up https://github.com/projectatomic/rpm-ostree/pull/1793
Which differs from jlebon's approach in that it just becomes the only option. That means pungi doesn't have to change.
Also I tested a FSB29 build using https://pagure.io/workstation-ostree-config/pull-request/109 and coreos-assembler, worked fine.
What's a bit more unknown is whether this would have any effect on Atomic Host or FIOT. I'm very doubtful it'd break anything though.
We could probably run a test on AH and find out. Also could have @pbrobinson confirm things look good to him before we make the change if we decide that's the way we want to go.
We still haven't gotten an answer to Owens question: what exactly is 'unified core', and why is it good for us ?
It just makes the compose side work more like the client-side. Mostly an implementation detail for the OS builder but it does have advantages/changes.
One good example is that it required https://github.com/projectatomic/rpm-ostree/pull/1808
The tracker issue upstream is https://github.com/projectatomic/rpm-ostree/issues/729.
Closing here but tracking this in the Fedora Silverblue upstream tacker: https://github.com/fedora-silverblue/issue-tracker/issues/333
Metadata Update from @siosm: - Issue close_status updated to: Duplicate - Issue status updated to: Closed (was: Open)