Application bundles in Gnome OS

[Alexander Larsson <alexl redhat com>]

While work on OSTree keeps going things have been kinda quiet on the
Application side. I'd like to start up this discussion as I think it
is both important and interesting, having designed two app bundling
framework prototypes before (glick and glick2).

I don't think glick2 is a perfect fit as is. It has some weak aspects,
like the lack of sandboxing and an over-reliance on fuse (with
possible performance/robustness/security issues), and some strong ones
(support for integrating apps with the desktop (desktop files,
mimetypes, etc) and in-memory deduplication of files). I'd like to
hear some implementation details on what Lennart has been looking at
though. Maybe we can merge the best from both worlds. See [1] for
techincal details on Glick2.

However, irrespective of the technical solution there are some
highlevel issues that need to be discussed for bundles to work.

For instance, what part of the core OS do we expect Apps to depend on,
and what parts would they need to bundle? Obviously Apps need to rely
on things like a kernel and an Xserver being around, as these can't
really be bundled. LibGL seems to also be in this category as its
essentially a driver which can't be bundled. It seems pretty safe to
also rely on some glibc version and the core X libraries. However, how
do we go from there? Are apps allowed to rely on bash? coreutils?
Gtk+? Python? "Robustness" says we should bundle as much as possible,
whereas efficiency says we should share as much as possible. Where do
we draw the line?

Another problem is that some things are not bundleable. For instance,
any kind of plugin/extension system break. I.e. you can't expect
themes or gio-modules like gvfs and dconf to work with a bundled
Gtk+/glib. And any kind of session-wide service that like gconf, dconf
or really any dbus using service need to be a unique instance and
can't be bundled.

The above seems to me to indicate that we need *some* level of
de-bundling and dependencies, even in an App-bundling system. However,
we'd like it to be much more coarse-grained than the traditional linux
packaging system. Basically, any non-extensible library should be
bundled with the app, and services or extensible libraries should be
grouped together in larger chunks of ABI backward compatible modules.
Maybe something like this: (note, these are just dependencies, not
leaf nodes like apps or the desktop)

core-1.0 (kernel,systemd,dbus,libc,X11,libGL,pulseaudio,policykit,bash,coreutils,etc)
glib-2 (glib + gvfs + dconf modules and services)
gtk-3.2 (cairo/pango/gtk + themes and modules compatible with Gtk 3.2)
gtk-3.4 (cairo/pango/gtk + themes and modules compatible with Gtk 3.4)
gstreamer-1.0 (gstreamer + basic set of plugins, you can ship extra
               plugins in your bundle)

All of these need to be parallel installable or otherwise isolated so
that multiple abi-incompatible version could be installed at the same
time.

Of course, anything like this brings in complexities wrt versioned
dependencies. What if you require a newer glib-2 than what's in
gnome-os 1.0? You can't bundle it, because then it doesn't work with
the system gvfs/dconf, and you can't bundle those because they are
session-wide unique services. I guess at some point you just need a
new OS version to run newer app versions, then its up to us to keep
old versions of the client libs work with new versions of the
services.

There is also the problem what to do with dependencies that have
unstable ABIs. Take for instance e-d-s, which keeps changing the
service ABI. Its easy to ship backwards compat client libraries, but
they won't actually work with a later version of the services. The
easiest solution to this is to just bundle all the e-d-s using apps
into one module "desktop" and forbid other apps from depending on it,
but that might not always work.

Basically, bundling doesn't completely solve the dependencies issues,
and we have a lot of work to do to try to balance these issues and
come up with a coarse-grained dependency system, and then to keep that
evolving in a backwards compat way.

[1] http://git.gnome.org/browse/glick2/tree/README