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 https://fedoraproject.org/wiki/Changes/OstreeNativeContainerStable. 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 1). 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 initrd. 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 reboot. 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: https://fedoraproject.org/wiki/Changes/OstreeNativeContainerStable. 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. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
