From Fedora Project Wiki

Revision as of 20:16, 22 August 2017 by Codonell (talk | contribs)

What is the base runtime interface?

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

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

This component version 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 distribution 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 by a group of committed developers, and to make their job easier we must formalize that validation. The easiest way to formalize the validation is to employ a more formal notion of API and ABI and validate it after the build.

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 inherent in this upgrade. 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.

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.

What does such an implementation look like?

The technology required to solve the above limitations exists, and an implementation is as follows:

  • We can use the libabigail project (https://sourceware.org/libabigail/) to serialize the ABI at the time of GA for the base runtime interface components. The serialized ABI is then used to validate all future builds. This would provide a level of automated assurance that has never been used before.
  • We can use an alternate system root for linking all applications. Within this alternate system root we provide curated versions of the required development files for the base runtime interface components. These curated versions are fixed at the GA versions and define the interface at the time of GA. The compiler colludes to search the alternate system root first when linking, and so will the static linker.

Using libabigail