Re: Application bundles in Gnome OS

[Alexander Larsson <alexl redhat com>]

On ons, 2012-10-10 at 00:44 +0200, Lennart Poettering wrote:
> On Mon, 08.10.12 16:49, Alexander Larsson (alexl redhat com) wrote:

> The way we invisioned this in the app executer stuff we'd like to add to
> systemd is we'd offer a number or profiles. Profiles could be something
> like "LSB 1.3", "GNOME OS 1.0" or even "NULL". Apps are marked with what
> profile they require and can only be executed on OSes that offer the
> specific profile. OSes can implement multiple profiles (and usually do),
> and apps can require multiple profiles.

This seems similar to my basic idea about the "platform", although in my
blog post I've been only talking about a single platform the "gnome os"
one. It makes sense to allow multiple platforms to be available.

> A profile is basically a definition of APIs that are supported. The
> effect is how much of the host OS is made available to the app container
> on execution.  The most drastic profile "NULL" would not make anything
> available at all, besides the naked system calls of the kernel. A
> profile "GNOME OS 1.0" would provide all APIs that GNOME considers
> stable enough to be part of such a profile (and really only those, which
> means no libegg or so even though libegg is always installed as part of
> GNOME). "LSB 1.3" would provide everything that is standardized by the
> LSB.

How exactly do you implement this though? Many libraries are ABI stable
"fronts" for implementation libraries that we want to be free to switch
out and make incompat changes to. For instance, gdk-pixbuf depends on a
bunch of image libraries, and gstreamer fronts a billion things. The app
need only link to the stable ABI, and should not in general be affected
by the private dependencies of it. But they *do* need to be availible to
the app at runtime in order for it to actually run.

> Note that by APIs I actually mean ABIs and bus interfaces alike. For the
> latzter this really means that apps cannot access any services on either
> the session or the system bus they are not whitelisted for.

There is even more things than ABIs and dbus interfaces. There is things
like which gdk-pixbuf plugins are available, what gstreamer plugins are
available, etc. And also, ABI compatibility is a tricky area. For
instance, there has been theming incompatibilities in Gtk3 CSS support
that while not actually breaking ABI could make apps using the old CSS
look bad. It would be quite specific apps and it would not be completely
broken, but its still a change. Also, bugs being fixed can also change
behaviour while keeping "ABI". Basically, ABI compat is a very complex
area that is not so black and white as the name implies.

A very common request for linux is to be able to run a stable distro but
then run the latest and greatest of some particular app. However, just
limiting what libs/files you put into the app container is not really
good enough for this. For instance you then might need to bundle e.g. a
more recent version of a dbus implementation (or some other kind of
single-instance service), which will conflict with the system installed
one already running in the session. Same with extensible libs. Say the
app needs a newer glib as it has some new function, so we bundle that,
but now that glib doesn't have support for the gio pluginins like dconf
or gvfs. Not sure how to handle this, but it seems like a pretty
important usecase.

> Bus interfaces not deemed stable and not listed in a profile should
> probably also not be made available to apps.

Is there a reasonable way to enforce this?

> OpenGL is a major point with ABIs here. If an app wants to use OpenGL we
> must mount this lib in from the host (since the nvidia binary drivers
> need that). OpenGL also pulls in a specific C++ API. This probably boils
> down to that OpenGL apps will necessarily be unable to be written with a
> "NULL" profile, unless they stick to software-only rendering.

OpenGL is especially problematic because there is no single "front"
library that apps link to. Instead each driver replaces the whole
library stack. It seems that the talk about the new OpenGL ABI might
help here.

Anyway, I think a NULL stack is not very useful, even for games. For
instance, it would not e.g. have X in it. Sure, you can bundle the x
client libs. But in practice a game will have dependencies on the X
server too (some specific extensions, the right GLX libs based on the
driver, etc). Instead i think we need a lowlevel graphical profile with
specific guarantees like the OpenGL ABI (at some version) and certain
Xserver and audio guarantees.