Base Runtime Fedora 26 MVP
The purpose of this document is to describe the Base Runtime minimum viable product (MVP) for Fedora 26, defining the role & structure of the Base Runtime module as well as its API.
The Fedora 26 Base Runtime MVP is defined with the following expectations:
- No explicit RPM repackaging besides any potential minimization work.
This means all the included binaries will be available in their standard locations. We’ll only focus on packaging changes related to the minimization effort.
- Everything included in Base Runtime is supported, i.e. marked as API.
Implied by the point above, everything in Base Runtime will be available in the standard paths, be it libraries or tools, and supported. Application-level modules may depend on these components and aren’t required to repackage them, unless they choose to do so.
- The module is defined as a set of binary RPMs.
Not being SRPM-based allows us to ship only a subset of generated binary RPMs, reducing the number of packages included both directly (through omitting certain binary RPMs) and indirectly (through smaller dependency chains).
- There is no requirement for Base Runtime to be structured in any specific way, therefore it’s entirely up to the Base Runtime team to decide what the module (or stack) is going to look like.
The goal of the Base Runtime team is to deliver a platform core that is both useful and minimal. The smaller the core, the easier is to maintain and guarantee the API/ABI stability. Our intention is to move large and/or fast-moving components out of Base Runtime into separate modules so that they can be developed at their own pace.
A good example would be the Python stack — Base Runtime includes a number of applications that require Python at runtime, however, we don’t want to deliver Python as part of the module due to its short development & release cycles and the possible associated API/ABI breakage. We will therefore implement packaging changes that will allow us to do this; e.g. we’ll ship the limited system-python stack and alter the included applications so they would work with it instead.
The team will deliver two base modules: Base Runtime and its build environment. Neither of the two is a module stack — there’s no internal structure whatsoever.
- The Base Runtime;; module provides components tied to hardware enablement, software and system management utilities and packages defining the common minimal buildroot.
- The build environment module provides components needed to build the Base Runtime module as well as itself, recursively (see the Building section for details).
The Base Runtime team will also deliver a temporary module, currently referred to as the Base Runtime build environment. This module contains all the build dependencies of components included in Base Runtime as well as its own runtime and build time dependencies, recursively. This is to both provide a build environment for Base Runtime and itself, and a way to bootstrap the build infrastructure.
- The buildroot of Base Runtime is Base Runtime itself and its build environment.
- The buildroot of the build environment itself, plus the Base Runtime module.
- Base Runtime provides all of its runtime dependencies.
- And finally the build environment requires Base Runtime at runtime.
Base Runtime provides the set of components needed to produce a source RPM and to assemble a binary RPM from binaries on disk, which can be used as a basic buildroot for layered module stacks. It does not, however, guarantee that all tools necessary to create a binary from source are present. This may require additional build modules.
The picture to the right illustrates the relationships between the Base Runtime module, its build environment and sample applications — one standalone and one including a framework module. The arrows signify build time (red) and runtime (green) dependencies. The framework module can be built separately or as part of the application stack.
For the Fedora 26 Base Runtime MVP, the Base Runtime API consists of all the binary packages included in the module as all the files are going to be available in their standard locations and no RPM repackaging is planned in this timeframe (see Expectations).
Base Runtime module API and filters are defined in the module's modulemd file in dist-git.