BaseRuntimeInterface

What is the base runtime interface?

The base runtime interface is a set of base runtime components, starting with glibc, which are designed to provide a compatible API and ABI for a certain amount of time, regardless of the exact version of the package installed.

The notion of a base runtime interface, and it's associated stability, already exists within Fedora and other distributions. The interface stability is achieved by freezing the version of specific components for the lifetime of a release.

This freezing process happens during the lead up to the release and culminates in a stable API and ABI being frozen for the duration of the entire Fedora release. For example glibc 2.26 is frozen for Fedora 27 as the glibc that will be used for the entire lifetime of Fedora 27.

The stability of the base runtime interface allows application developers to target Fedora 27, build applications, and deploy them to Fedora 27 with the knowledge that these interface will not change for the duration of the release (a major version of Fedora).

What can we make better?

The current implementation of the base runtime interface has two limitations:

• Loose validation that the base runtime interface doesn't change over the course of the major release.

• The base runtime components can't be easily upgraded to support newer features for use by applications that need those features.

First and foremost the stability of the base runtime API and ABI is paramount. It is the stability of this interface that provides the basis for a stable distribution. Our current base runtime interface in Fedora is maintained stable by a group of committed developers, and to make their job easier we should formalize that validation. The easiest way to formalize the validation is to employ a more formal notion of API and ABI, and thanks to the libabigail project (https://sourceware.org/libabigail/) we now have such a capability. With libabigail we can test from release to release that the API and ABI are stable.

Secondly, having the ability to upgrade base runtime components would allow a stable distribution to upgrade these components to newer version without the need to go through a full release process. The base runtime components could be upgraded on a rolling basis or as needed based on other requirements e.g. new ISV application needing a new glibc and a desire from users to deploy that in the existing Fedora major version.

The difficulty with upgrading base runtime components has been that such an upgrade inevitably leads to a base runtime interface change which requires packages to either explicitly or implicitly depend upon the new component (Florian Weimer wrote about the various difficulties here . This tight coupling of implementation and interface makes it difficult to upgrade the base runtime components without requiring all users move to the new base runtime component (since implicit RPM dependencies on symbol versions would require this). If we could split the implementation from the interface we could allow the distribution, say Fedora 27, to target a known interface for Fedora 27, and as long as the implementation was backwards compatible with this interface, then the implementation could be upgraded as required.

Therefore the benefits of fixing the above two limitations would be:

• Formal API and ABI validation allowing for measurable progress for stability guarantees.

• Separation of implementation and interface for backwards compatible packages, allowing for package upgrades or rebases to support newer software on existing releases.