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.
Expectations
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.
Minimization
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.
Structure
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).
Building
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.
API
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).
The specifics are not yet set in stone; the current API can be extracted from the Base Runtime module metadata file.
Filters
For various reasons documented below (work in progress), the following Base Runtime source packages require binary package filtering. Module authors wishing to package the filtered binary RPMs should consult their plans with the Base Runtime team. The list is exhaustive:
- audit
- babeltrace
- chkconfig
- cracklib
- cryptsetup
- cyrus-sasl
- dbus
- dracut
- emacs
- fedora-release
- file
- python-magic and python3-magic (the Python bindings for the libmagic API) filtered out because of dependency on python/python3; no package in Base Runtime depends on them
- freetype
- freetype-demos filtered out because of its dependency on libX11; the utilities it provides are not immediately useful and no package in Fedora currently depends on it
- gettext
- emacs-gettext filtered out because of dependency on requires emacs and emacs-nox
- glib2
- glibc
- gnupg2
- gnutls
- groff
- iptables
- kernel
- krb5
- libcap-ng
- libcroco
- libidn
- libpwquality
- libselinux
- libsemanage
- libtool
- libverto
- libxml2
- lvm2
- nghttp2
- openldap
- openssl
- python3
- qt5
- qt5, qt5-devel and qt5-rpm-macros filtered out, leaving only qt5-srpm-macros in Base Runtime; this shouldn't affect anybody in F26; in the long term, packaging the macros files as separate SRPMs would be preferrable
- redhat-rpm-config
- rpm
- sqlite
- systemd
- texinfo
- util-linux
- vim
- vim-X11 filtered out because of its runtime dependency chain (libX11, gtk)