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

[Sébastien Wilmet <swilmet gnome org>]

On Thu, May 12, 2016 at 05:48:29PM +0200, Alexander Larsson wrote:
> 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. 

At some point, we need to trust the maintainers for doing a good job.

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

I think there are many small programs developed on Linux but that are
never packaged in a distro, but rely on libraries installed by the
distro. Think about in-house programs developed at a small organization,
for example.

In GNOME, it is very unlikely that the API or ABI is touched in a new
*micro* version. When it does, there is normally a new micro version
fixing that.

But I think what you mean by "ABI" actually also includes implementation
details. Of course a new micro version can change the implementation, to
fix a bug. An application should never rely on implementation details,
it should rely only on the API, i.e. what is documented. But
unfortunately, library developers in GNOME often don't care a lot about
the documentation, and app developers often read the library code or
proceed by trials and errors, and thus depend on implementation details.

If the goal of the GNOME runtime is to not break any app, even those
that depend on implementation details, then it makes perfect sense to
not include a lot of things in the runtime, and be cautious when doing
updates. But in that case, the stability that you guarantee is beyond
the API/ABI. As a reminder, the I stands for "Interface". By definition,
implementation details are not part of the interface, even for the
binary interface.

So, nothing prevents GNOME from creating a GNOME-extra runtime with the
missing libraries (libraries useful for apps, of course… [1]). GNOME-extra
would guarantee API/ABI stability during a specific version of the
runtime (e.g. 3.20). But implementation details can change. As long as
the stability guanrantees are well documented for each runtime, with an
explanation of the risks, it should not be a problem. A developer who
wants the highest stability guarantees can use the GNOME runtime, and a
developer who prefer automatic updates to the latest micro versions of
the libraries (to get the latest bug fixes and translation updates) can
use the GNOME-extra runtime. (Exactly as the GNOME runtime is based on
the freedesktop.org runtime, the GNOME-extra runtime would be based on
the GNOME runtime).

As a library developer, I prefer that apps use the latest micro versions
of the libraries that I develop, for obvious reasons. If it is not the
case, users start filing bugs in bugzilla for things that are already
fixed upstream. And if app developers or distros don't pick up the new
micro versions that I release, what's the point of doing them then? I
care about the software that I write to be bug-free (apparently it's not
the goal of all developers, unfortunately). For a software to be
successful, it needs to be as bug-free as possible. Updating to the
latest micro versions is the bare minimum to attain that goal. There is
nothing worse to see that a distro/flatpack is still at version 3.X.0 of
a library when upstream is at version 3.X.4, fixing important bugs.

[1] A good chunk of this thread was just to explain "no, of course I
don't mean that, I mean that". I thought the context was sufficient to
understand what I meant implicitly. I'm not that dumb.

--
Sébastien