On Fri, Apr 12, 2019 at 3:27 PM Simon McVittie wrote: > Flatpak treats /usr as immutable (with the exception of mounting > "extensions" on pre-prepared empty directories) and mounts it read-only in > the container. If it didn't, it wouldn't be able to use content-addressed > storage (the storage can't be content-addressed if the content changes). > In the usual way to use Flatpak, with a shared runtime for a family of > related packages like "the GNOME apps", apps would end up accidentally > or deliberately modifying each other's runtimes if they weren't read-only.
I expected the Flatpak /app directory to also be entirely read-only, are there parts of /app that are not read-only? > If the user-facing leaf package is really installed in the runtime, with > a different runtime for each user-facing leaf package, you're right that > the Flatpak app could mostly contain symlinks into /usr. A few metadata > and integration files that get "exported" to the host system (such as > .desktop files and icons) would have to be copied instead of symlinked, > because the host system needs to be able to read those without entering > the container. It sounds like my idea might be a viable way to generate automatically Flatpaks directly from leaf Debian packages then, thanks for the info. I might at some point take a look at adding such a mode to flatdeb, would you accept having that as an option? > flatdeb installs apt/dpkg/essential, but then deletes apt, dpkg and ... Yeah, I noticed that so I was glad when mmdebstrap's sub-essential stuff came along. > The matching SDK runtime that is used to compile apps I don't know enough about SDKs in the Flatpak world, would they contain something like the Build-Depends and their recursive deps? > Instead of using sudo or ssh to a remote (usually virtual) machine to > get root so that it can run debootstrap and dpkg, flatdeb now runs debos > on the local machine. This means it's root in debos' temporary qemu VM, > and doesn't need privileges other than /dev/kvm access in the host system. That sounds like a much better design. > In principle there'd be nothing to stop debos from using something > like user-mode-linux as an alternative to qemu/KVM. I guess you could also use container tools like systemd-run with user namespaces (once those are enabled by default)? > One per desktop task, plus one for the Priority >= standard default > CLI installation, would be quite a lot of data but could be good for > bisecting, yes. I'd suggest doing this with debos, which has built-in > support for committing trees to libostree and doesn't need root on the > host system. Cool, thanks for the information :) -- bye, pabs https://wiki.debian.org/PaulWise
