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 _______________________________________________ gnome-os-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/gnome-os-list
