From Fedora Project Wiki

Line 8: Line 8:
* There's an incomplete [[Changes/Host_and_Platform|Fedora 27 Host and Platform Change Proposal]]
* There's an incomplete [[Changes/Host_and_Platform|Fedora 27 Host and Platform Change Proposal]]
* [ Release Engineering ticket #6791] about having the new bootstrap tag created is currently blocking any practical Host and Platform development
* [ Release Engineering ticket #6815] on reviewing the abovementioned change proposal
* [ Release Engineering ticket #6791] on having the new bootstrap tag created is currently blocking any practical Host and Platform development
== Implementation ==
== Implementation ==

Revision as of 18:53, 25 May 2017


Host and Platform is a set of modules or module stacks defining the base operating system, effectively replacing Fedora 26 Boltron Base Runtime module & concept.

The new modules target modular Fedora releases, starting with version 27.

Current status

Planning and initial Base Runtime transformation work is in progress.


The end goal is to provide the base operating system content in a way that allows for hardware enablement and general userspace separation, enabling different update cadence and life cycles for each of the two parts. The concept is defined by the following set of objectives and expectations:

  • Host and Platform should be built and composed as modules, benefiting from all the pipeline enhancements Factory 2.0 provides and will be distributed with useful module metadata
  • The Host part should deliver hardware enablement components such as the kernel, bootloaders, firmware, additional device drivers and components closely linked to these
  • The Platform part defines the operating system release and includes various base userspace components ranging from the C library and init system to system management & deployment tools, container runtime and possibly several services commonly considered to be part of the base system experience
  • The Host and Platform modules should be independent, making it possible to run the same Host with different Platforms and vice versa
  • Each of the two modules has its own life cycle, update cadence and versioning scheme
  • The Host can only be experienced through the Platform
  • The Platform part will provide all the content needed to produce container base images; the Platform can therefore run without the Host when inside a container
  • Both modules will be built in a shared, self-hosting buildroot (also known as the Bootstrap module) providing all the build time dependencies needed to build the Host and Platform as well as itself
  • While independent on the source level, given the shared build environment the modules' binaries will be tightly coupled and the Host part will therefore need to be built for every supported Platform it's intended to be distributed with
  • The Platform module with provide the minimal build environment for application level modules -- this means that modules built against a certain version of Platform will be built using the Platform compiler; this doesn't affect what additional compilers are available to the end users, for example via application level modules


At minimum the team is going to deliver three modules, one of which being an unsupported implementation detail only that won't be part of the Host and Platform compose.

  • The Host includes the kernel, bootloaders, firmware, out-of-tree device drivers and components tightly coupled with any of these
  • The Platform includes the C standard library, the init system, basic system tools, filesystem and networking utilities, system Python runtime, system management and deployment tools such as dnf and anaconda, container runtime(s) and possibly additional system services and components necessary to provide a reasonable base system environment
  • The Bootstrap module includes a self-hosting package set needed to build the Host and Platform modules. An implementation detail only. Host and Platform are subsets of this module. The sources are available but its binaries are not part of the compose.

Host and Platform modules might be implemented as simple modules or module stacks, depending on what provides more practical value. Given that the content of each will be bound by the same life cycle and update cadence, we don't expect to split them into sub-units unless necessary.

The Host module might be a module stack from day one to simplify packaging of the UEFI bootloader.

The Bootstrap module will be initially created by manually tagging traditional Fedora binaries into a special purpose, module-like tag. The module is self-hosting so that it can later rebuild itself, as well as serve as a base for building future releases and derived distributions.

Differences from Base Runtime

Base Runtime becomes Host and Platform

Fedora 26 Boltron Base Runtime module was created with a different set of requirements in mind: it was meant to provide a minimal bootable environment with hardware enablement, init system, basic system tools and a minimal package manager. Unlike Host and Platform, Base Runtime is usable on its own.

To build Base Runtime we also created a self-hosting buildroot module called Bootstrap by hand-selecting builds from traditional Fedora releases, mostly Fedora 25, 26 and Rawhide. By definition, Base Runtime is a subset of Bootstrap. Bootstrap is an example of an "implementation detail only" module that isn't part of the compose and distributed in binary form, despite being tracked in the product database and dist-git, and having its own module metadata. The Bootstrap module needs to be self-hosting to break the dependency on the traditional release and to allow us to stabilize, fix and rebuild the buildroot independently if required.

Base Runtime is both smaller and larger than Host and Platform -- it provides the basic functionality of both but the Base Runtime userspace package set is much smaller than that of the Platform.

Presentations and blog posts

There are currently no Host and Platform specific materials besides this wiki page. See Base Runtime presentations and blog posts for Base Runtime-era decks and articles.

Get in touch

Get in touch with us on the devel mailing list and our IRC channel, #fedora-modularity.