#137 Move to use unified core composes
Closed: Duplicate by siosm. Opened by jlebon.

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:

  1. getting the Silverblue package set to work in unified core mode, and
  2. teach pungi to pass --unified-core for Silverblue and IOT (another path, though more effortful is migrating them to use coreos-assembler, like FCOS)

Can you describe or link to what the difference is - the help for rpm-ostree tree compose says:

--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.

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)

Metadata