After reading this, I think there's a false dichotomy here:
On Tue, Jul 11, 2017 at 9:26 PM, <mcatanzaro(a)gnome.org> wrote:
On Tue, Jul 11, 2017 at 7:45 PM, Kevin Kofler
> There ought to be better ways to sandbox applications than to turn them
> what is essentially a full container (i.e., almost a full VM, only minus
> kernel), bundling all the libraries. The split into an application and a
> runtime that Flatpak does is only a partial workaround.
I don't think there are better ways to sandbox applications. Sandboxing is
what has really sold me on Flatpak.
Flatpak provides two things that are very nearly orthogonal: packaging
and sandboxing. Packaging is the system of bundles, apps, runtimes,
etc that allows you to build a Flatpak, send it to a different
machine, and run it there, even if the other machine runs a different
Sandboxing is Flatpak's system of portals, confinement, etc.
Aside from the fact that both are based on namespaces, I see no reason
at all that they need to be conflated. It should be entirely possible
for Flatpak ro run an "app" that is actually a conventional RPM
installed on the host system using host libraries. Flatpak would just
map all of /usr into its namespace rather than mapping a container
bundle into its namespace. The sandbox would work exactly the same as
for any other Flatpak except that the sandboxed app would be able to
read all of /usr. Arguably, in a model where all of /usr is visible
in the app's namespace, development and debugging might be
Perhaps Fedora should consider a scheme where graphical application
RPMs are augmented with the metadata needed to run them inside Flatpak
while still packaging them the old-fashioned way with old-fashioned
RPM library dependencies and old-fashioned build tools. This would
almost certainly entail modifications to Flatpak, but I bet they'd be
fairly minor modifications and quite possibly much less complex than
all the tooling needed to get the average graphical application RPM to
build a functional Flatpak bundle.