Re: GNOME xdg-app runtime doesn't follow the jhbuild modulesets

[Alexander Larsson <alexl redhat com>]

On tor, 2016-05-12 at 12:50 +0200, Sébastien Wilmet wrote:
> On Wed, May 11, 2016 at 09:39:37AM +0200, Alexander Larsson wrote:
> > There seem to be a fundamental disconnect here wrt why there are
> > runtimes and how they work.
> >
> > The reason there is a runtime/app split is *not* to make it easier
> > to
> > build applications. Bundling is a *fundamental* aspect to how xdg-
> > app/flatpak works, and you can't expect any app to not bundle a
> > library
> > or two. This means we need to make the tooling and the upstream
> > modules
> > make it as easy as possible to do this.
> >
> > The reason we have a runtime is to share maintainance load and
> > experience. The most imporant part of the runtime is the core:
> > libc,
> > openssl, image libraries, opengl, bash, coreutils, compilers (for
> > the
> > sdk), etc. These are things that require a special kind of
> > developer,
> > and is not something that you want to force application developers
> > to
> > know about. We also want to share the burden of security updates,
> > so
> > that the core stuff gets security updates for all apps without the
> > app
> > developers having to be on-top of glibc errata every weekend.
> I understand all the challenges of creating and maintaining a runtime
> containing low-level libraries.
>
> But this is not very different from what distros already do. The
> difference is that the runtime is decoupled from the distro version.
> Doing security updates to a specific runtime is, at the end of the
> day,
> not very different from doing security updates to a specific LTS
> distro
> version.
>
> I suppose that not all runtime versions will have long-term support.
> And
> in practice application developers will be encouraged to use an LTS
> runtime, right?

Yeah, for stable releases at least.

> > But, if a runtime starts getting too much stuff in it then this
> > becomes
> > a problem. Its slower to build, larger to download, harder to
> > maintain,
> > it potentially updates more often, and it quickly gets full of old
> > releases that gets in the way of apps bundling their own newer
> > version.
> For GNOME libraries, it is not recommended to mix different minor
> versions. E.g. it is not a good idea to use GTK+ 3.20 with
> GtkSourceView
> 3.22. So if an application uses the GNOME 3.20 runtime, it should
> also
> use the 3.20 version for other GNOME libraries.
>
> So if there is a runtime available with all GNOME libraries, the
> problem
> of "it quickly gets full of old releases that gets in the way of apps
> bundling their own newer version" doesn't exist.

I think this is a pretty naive view of things. If we dump a lot of
libraries in our runtime and agressively update them to new micro
releases then we will run into a lot of risks wrt ABI instabilities. 

Historically applications in distro repositories are updated in
lockstep with their dependencies, so they are updated pretty freely.
And in case of bugs being reported apps are just updated to fix it.

However, a runtime has a much stricter behaviour, as it needs to
continue to run 3rd party apps that we have no control over, and in
fact may not even be aware of. So, this is not really like a distro,
its more like the ABI requirement of binary-only OSes like windows.

> > Runtimes have a much higher guarantee of ABI stability than
> > anything
> > anyone in the free software world historically have had to deal
> > with,
> > because they are a long term guarantee that 3rd party binaries will
> > keep working against it. This means e.g. no or very careful version
> > updates and bugfix backports. 
> For GNOME libraries, if maintainers do their job well, updating to a
> newer micro version (e.g. GNOME 3.20.1 -> 3.20.2) doesn't break the
> API/ABI. So you can normally safely update to the latest micro
> versions
> of each GNOME library, and this in an automated way, running the unit
> tests etc (continuous delivery).

In theory yes, but the more code is added, the more risk there is, and
the harder it is to avoid ABI regressions.

> But maintaining API/ABI across runtime versions is another story.
> E.g.
> the runtime between GNOME 3.18 and 3.20. The set of libraries present
> in
> the runtime could change from one version to another. Sometimes a
> library becomes deprecated and is replaced by a new one. So the
> runtime
> needs to include that new library and at some point it can remove the
> deprecated one. As soon as this is well documented, it is not a
> problem.
> If an application wants to use the newer runtime version but still
> wants
> to use the deprecated library, it can bundle it.

Yeah, being able to break ABI over major runtime versions is one of the
main selling points of xdg-app. Old apps can keep running against
exactly the old code they were tested against, and if they are updated
to use the new ABI the developers can properly test it for that and
make sure it works.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
       alexl redhat com            alexander larsson gmail com 
He's a war-weary arachnophobic vagrant from the Mississippi delta. She's 
a strong-willed junkie research scientist who inherited a spooky stately 
manor from her late maiden aunt. They fight crime!