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

[Sébastien Wilmet <swilmet gnome org>]

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?

> 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.

> 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).

So for a specific runtime version, e.g. GNOME 3.20, I don't think it is
hard to maintain the API/ABI. And again, I don't think it is very
different from what stable distros already do. It is "just" that the
runtime is decoupled from the distro version.

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.

--
Sébastien