Re: Sandboxed Gnome apps

[Christian Hergert <christian hergert me>]

On 09/04/2014 10:05 AM, Alexander Larsson wrote:
> I don't necessarily agree to the use of btrfs[1] for the images, but
> otherwise I think this is generally the right approach for desktop
> apps. However, in order to actually be useful for desktop apps there
> is a lot more work required. I've recently started looking at what
> Gnome needs to do here, and wanted to start a discussion about this.

I rather like it, but we should definitely consider whether or not we
need to care about *BSD's, and the availability of Btrfs.

> 3. A SDK and other tooling
>
> There needs to be an easy way to build an application against the 
> gnome runtime. This means we need to ship a SDK with all the
> development stuff for the runtime (headers, symbols, debug info), as
> well as tooling to make it easy to use those without risking any
> contamination from the host. We also want to have tooling to make it
> easier to bundle libraries, as we don't want every app author to have
> to package everything from scratch.

I hope to be able to use this from Builder.

Especially if it is available via OSTree. I imagine a dialog in Builder
to manage your local SDK's, and downloading the updates trivially.
(Android SDK has this too). This will allow me to get things setup in a
VM/Simulator so that developers can test against multiple runtime.

> I've recently started looking at how 1-3 could be done. I've
> experimented with openembedded which is a very nice way to do cross
> compilation that also lets you create SDK. However, some of stuff, in
> particular gobject-introspection is very tricky to do right when cross
> compiling. I've now changed over to the mixed model that
> gnome-continuos is using where openembedded is used to build a base
> containing the build environment, and the rest is built in a chroot.

You've seen Yocto w/ meta-gir?

> Hopefully I will have some initial cut of a runtime based on
> gnome-continuos some time next week. This will give us a runtime, but
> also a lot of stuff that can be used to make the SDK.

Once you have this working, I'd love to start hacking Builder to
download images if we can put them in a discoverable location.

> We need to start looking into exactly what the runtime should include
> though. Obviously it should contain glib, gtk+ and the gnome platform,
> but we also need to pick the lower level dependencies (glibc, X, etc)
> as well as some level of standard unix tools.

Is there any sort of "dependency" chain here? Were there is something
like a reduced LSB for the core utilities so our runtime, and KDE's, and
others need not all share this effort?

> There are also lots of technical issues. For instance how do we ship
> mesa and DRI drivers which have dependencies on the kernel part of the
> driver? How do we support e.g. the nvidia drivers in this? Do we need
> some kind of overlay for the runtime image for local hardware drivers?

Do we ship those in our Runtime, or is our runtime simply laid over the
core platform?

> [1] I think using btrfs send/recieve to upgrade apps is a nice idea
> but not really all that important. You need all sorts of contractions
> to produce such a diff if the new version is built from scratch, and
> its unlikely that a simple "tar up the changed files" approach (which
> is much simpler) would generate a substantially larger diff.

This is really cool when you have more than a single machine in a
physical location. You can avahi+btrfs send/receive platform upgrades. I
think davidz did something like this for ChromeOS in their updater.

-- Christian