Fedora Modularity Introduction
This introduction to the Fedora Modularity plan is based on Langdon White’s Flock 2016 presentation, and since the design/plan is still in the early stages it is reasonable to expect changes, especially involving the smaller details. This is intended to be a brief, high level introduction to the Modularity effort, not a comprehensive description. Current, and more detailed, information can be found on the Fedora Modularity web site.
Traditional Fedora systems have relied on individual application packages/RPMs and package groups for the installation and management of software on the system. While this model is well understood by both developers and administrators, it doesn’t fit well with many of Fedora’s long term goals, or the technical and usability goals of a solution based OS distribution. The proposed Modularity design intends to correct this by moving the focus from individual application packages to solution based modules which provide integrated, configured, and tested bundles (modules) that can be quickly installed on a system.
Initially these modules will rely on RPM packages to deliver the included packages, but the design of the module platform is such that modules can be composed from any number of application package formats, including containers. Modules can be used to deliver almost any data to the system, including a nested stack of other modules.
Another goal of the Modularity effort is to decompose the monolithic Fedora distribution into a collection of modules, each with different support lifetimes. For example, the core “base-runtime” module, with a relatively long support lifetime, will provide a very stable set of applications, libraries, and interfaces. Higher level solution specific modules can have varying levels of support lifetimes; longer lifecycles offer better support and stability, while shorter lifecycles trade stability for the ability to better track upstream development.
The Modularity effort presents a number of opportunities for us to rethink how we deliver SELinux policy in Fedora, but with those opportunities comes challenges. The shift towards a modular, solution focused OS offers us the chance to provide a default SELinux policy that is better matched with usage requirements while at the same time reducing the runtime policy size (better performance, smaller memory footprint, etc.). However, modularizing our SELinux policy delivery introduces new concerns around dependency management, object labeling, and support that will need to be addressed.