Re: Sandboxed Gnome apps

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]