Re: Sandboxed Gnome apps

[Alexander Larsson <alexl redhat com>]

On ons, 2014-09-10 at 11:02 +0200, Bastien Nocera wrote:
> On Wed, 2014-09-10 at 09:11 +0200, Alexander Larsson wrote:
> > The runtime would bundle the gio library and the gvfs gio module, but
> > not the gvfs daemons. Rather, the gvfs daemons would be running in the
> > host. We want an older version of an app+runtime to work on a newer
> > host, so that the older gvfs gio module must be able to talk to a newer
> > version of the gvfs daemons. Historically this has not been the case,
> > we've been doing incompatible breaks in the internal gvfs protocols
> > because we assumed that gvfs modules and gvfs daemons are always updated
> > in lock-step, but we can no longer assume this.
>
> Or you could backport any ABI breaks to older versions of the library,
> so all of your run-times would be updated. When, Apple or Google ship a
> new version of their mobiles OSes with support for older versions, I
> doubt that the older versions are actually the older version, but they
> are libraries with the same behaviour made to run alongside the newer
> frameworks.
>
> That's assuming that the ABI changes don't change behaviour obviously.

True, on could make the old apps require a new version of the old
runtime. But ideally we shouldn't require this, unless keeping ABI for
the IPC is *really* hard as you then need to start maintaining old
client libs. 

Historically we have just not really cared at all about this, and this
is what has to change, we have to start caring.

> > > <snip>
> > > > 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.
> > >
> > > This will give us a runtime that's not easily reproducible or trackable.
> >
> > Using gnome-continuous in an incremental fashion will give us a constant
> > source of testing runtimes for the next version. However, the final
> > released runtime needs to be done from a manifest that specifies exact
> > versions of every module and does a build from scratch. That should be
> > reasonably reproducible, or do you object to that too?
>
> That's doable as long as:
> - we keep copies of the git trees used to create the various runtimes

If we're using an unchanged upstream git tree at freedesktop.org, do we
really need to keep a copy of it?

> - we keep branches for each runtime version
> - git trees don't use non-fast-forward merges

One way is for the manifest file to point to a specific branch of each
module. Another is to point to an exact commit id, then you know
*exactly* what piece of code was built. The commit could be just a
normal one, or on a special branch with some added fix. 

> > > > Well, this was a lot of text from my side with nothing practicaly
> > > > useful yet. I think its good to get people started thinking about these
> > > > things though, and I'll keep people updated as I make progress actually
> > > > building something.
> > >
> > > My advice is, as for the test ISO images where we scrub Fedora branding
> > > out of the images, to use an established distro to base our reference
> > > image and SDK. I don't particularly mind if it's Fedora, Debian or
> > > something else, those who do the work will get to choose :)
> >
> > While I think this will let us avoid a bunch of work it think it may be
> > a very hard sell politically. Also, depending on what we ship in the
> > runtime I think you're overestimating the amount of work that we have to
> > do.
>
> I don't think I'm overestimating it one bit. You're more than welcome
> experimenting with it, but I wouldn't want you to become a build monkey,
> replicating work done in distros when there are plenty of other things
> that could be worked on.

Well, a lot of the build is just inherited from openembedded, and they
have some maintainance already.

> I also don't fancy somebody non-qualified to start cherry-picking glibc
> or NSS "fixes". But below you say that you expect distros to ship
> security updates. We'd create a runtime that won't be updated for each
> GNOME version, security holes and all?

No, i think we want to do security updates, and i think other distros
would want to pick those up as we release them. However, I can also see
other distros wanting the ability to quickly spin their own fixes.

> I'll stop being the fearmonger and let you get on with it, and I hope
> it's as straight forward as you think it is.

Things are never as simple as you hope they are unfortunately. :)