On Thu, May 25, 2023 at 4:02 AM Florian Weimer <fwei...@redhat.com> wrote:
> * Owen Taylor: > > > On Fri, May 12, 2023 at 1:34 PM Florian Weimer <fwei...@redhat.com> > wrote: > > > Do you have a pointer where I can read up on the current approach? > > > > Some references that I found quickly: > > > > https://docs.fedoraproject.org/en-US/flatpak/concepts/ > > https://docs.flatpak.org/en/latest/basic-concepts.html > > > > But neither goes into a lot of detail to motivation. I'm certainly > > willing to describe things in more detail or look around further if > > you still have questions. > > As far as I can see, it doesn't explain why we need rebuilds. > > Toolbx seems to be able achieve something similar without rebuilds. In the docker/oci ecosystem, layers are explicitly dependent on the exact underlying layers. If I modify a base image to upgrade one library, I have to rebuild images that depend on it. Similarly, once you've created a Toolbx container based on a verison of the image, you can't replace the image without recreating the container and losing local modifications. If Flatpak was based on docker/oci, then every time a single library in the runtime was modified, all 2000+ apps on Flathub would need to be rebuilt and the upgraded versions downloaded by every single user. In the ideal case, the upgraded application layers delta-compress well, but we're still talking about a huge amount of wasted resources. It works better for server-side containers because of datacenter-level networking and resources, and because server-side container images are often simpler and are based on simpler base images. So, we need to preserve the ability to separately upgrade the application and the runtime. This is currently achieved in Flatpak by the "low-tech" way that the runtime is in /usr and the application in /app and we mount those together into final namespace. If we want to achieve the same thing with everything in /usr, then we have a series of technical challenges to overcome. Among others: * We need a way to merge filesystems (fuse-overlayfs, composefs, huge quantities of bind mounts, hardlink trees...) * We need to rebuild files that can contain data from both parts (/etc/ld.so.conf, /usr/lib/fontconfig/cache, etc.) * We have to handle the case where the application layer needs to bundle a newer/different version of a library than the runtme These aren't impossible to solve, but to come up with solutions, implement them in the Flatpak codebase, validate them with real applications, update all the build infrastructure is a large (year or years scale) project. Beyond that, you have to convince upstream Flatpak that this is worthwhile - to add a whole second mode of operation for Flatpak when the current mode of putting application code in /app largely works fine in the "normal" case where the application is rebuilt from source code. So, to recap, Flatpak separates out /usr and /app because that allows the runtime and application to be separately upgraded. Modifying Flatpak to solve that problem in a different way would be a technically difficult and long process that, even if we had the resources to do it, would not solve immediate problems with our dependency on modularity. - Owen
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
