We will be writing a series of blog posts regarding the project to help the Modularity effort move forward. Some of the posts will be about “Why?” and some will be about “How?” As the first post in the series, this article is about “Why?”

The Rings Proposal and the Modularity Objective are both about big ideas and a long-term vision. And it should be all those things. Grand visions are how Fedora is what it is today.

Why is modularity important?

However, modularity can be captured, at its essence, in solving one problem. Namely, how do we allow an application like Puppet[1198366][809911], an important application to Fedora, to proceed at a pace dictated by the upstream project? How can we make Fedora an inviting place for Puppet to experiment with its latest versions as well as running its production version?

Achieving modularity by compat packages

One solution, compat packages. Fedora sometimes provides compat packages to support applications leveraging older components.  The compat solution satisfies a lot of users and applications but is a significant amount of work for the distribution’s contributors.

We also sometimes need to hold back the latest version of something to wait for the next release of Fedora. Recently this happened with Docker. Obviously, for many users of Fedora, this is a good thing, but for the people actively working to improve Docker and containers, this can force them to work on a different platform.

We need to allow applications to chose to deviate from other applications and provide the libraries they wish to use. We also need the package manager to track the independent sets of dependencies.

Getting modularity to work

We need a few things to be supported to make this work. One, we need to be able to define an “application” (or module) without resorting to bundling. We also need an infrastructure that supports automatically tracking the changes to components of a module, rebuilding them as appropriate, and testing them with the new component(s). We also need the client tooling (e.g. dnf) to support tracking a module (installation and update). Finally, some modules may not pass tests with a patched component, so we also need to provide the end system owner options for what to do.

Modularity can help Fedora better embrace applications, at any point in their lifecycle, without ceding control of the security and safety of the end systems to the application providers.

---

Next time, depending on feedback on this post, will be an article about why modularization helps system administrators.