The main issue with this change for Silverblue/Kinoite is that this introduces client side
layering by default for all users.
To understand why this is not a good idea, I need to recap a few things: how rpm-ostree
client side layering works, the general goal behind rpm-ostree and image based updates and
what we're trying to do in
First, let's start with rpm-ostree client side layering.
When you update a "pristine" Silverblue system, the following happens:
1. rpm-ostree looks into the remote ostree repo for the latest version commit and
downloads all the files needed for it into the local repo.
2. Once this is done, it creates a new deployments, which is a new copy of /usr made
mostly of hardlinks to the repo.
3. Then you can reboot and you're done.
When you enable client side layering, because you want to change something in the image,
remove a package, add a new one, etc., the following happens:
1. rpm-ostree has to fetch the needed files into the repo like in the previous case (step
2. But then, instead of creating directly creating a new deployment, it creates a
temporary one with the content of the latest commit.
3. From this temporary deployment, rpm-ostree is able to fetch all RPM metadata from the
Fedora repos, then resolve the dependencies for the added/replaced/removed packages and
download the RPMs as needed.
4. It will then create a temporary writable overlay on top of the temporary deployment,
perform the package installations, replacements, removals and optionally rebuild the
5. Then it will process the files in this overlay to create a new ostree commit.
6. Finally, it will deploy this new commit into a new deployment to be used after a
Given the additional steps required when client side layering is used, updates will take
longer to be downloaded, prepared and installed and will require more CPU and memory.
Additionally, any operation done on the temporary deployment may fail: missing
dependencies, conflicts, wrong package signatures, etc.
The idea behind rpm-ostree hybrid model is that you don't have to manage package
conflicts, installation, etc. on the client side and instead rely on the server composing
a working image for you. With client side layering, this guarantee goes away and the user
will have to intervene when it fails.
This is the main reason why we recommend to be careful with client side layering: it may
fail and you'll have to figure out why, just like you need to figure out dependency
resolutions issues on a classic DNF based system.
The main goal of Silverblue is to get rid of this issue in the first place by relying only
on images by default. Users may choose to override things in the image but they would have
to do that on purpose, via the command line, hopefully knowing that they are now
responsible when something fails.
Note that neither GNOME Software nor Plasma Discover support managing client side layered
packages right now. GNOME Sofware pre-downloads packages, essentially making the first
step invisible to the user and only then notifies the user to trigger the 2nd and 3rd
steps. Plasma Discover is not yet capable of doing that but I'm working on it.
So yes, client side layering is fully supported in Silverblue/Kinoite as it enables
debugging, testing, workarounds, etc. but we don't want to expose users to it by
default as this is not a good user experience.
One solution to reduce the time taken by client side layering and those issues mentioned
above is to move the package overrides back to the server side by using a layering
approach similar to the one used to build containers. This is the goal of this change:
. It enables users to
make custom builds of Silverblue/Kinoite with their own selection of packages and changes
and then to distribute them as an image to their systems, getting the full benefits of
pure image based updates back if they don't do any local changes anymore.
I hope that explained things in more details.