The Modularity and Server Working Groups are very excited to announce the availability of the Boltron Preview Release. Boltron is a bit of an anomaly in the Fedora world — somewhere between a Spin and a preview for the future of Fedora Server Edition. You can find it, warts (known issues) and all, by following the directions below to grab a copy and try it out.

Fedora’s Modularity Working Group (and others) have been working for a while on a Fedora Objective. The Objective is generically called “Modularity,” and its crux is to allow users to safely access the right versions of what they want. However, there are two major aspects of “accessing the right versions.”

The first aspect deals with the problem of installing multiple versions of something in the same user space. In other words, the user may want httpd-2.4 and httpd-2.6 installed and running at once. There are countless solutions to this problem, with different tradeoffs and primary goals. For example:

  • Python natively allows this
  • Software Collections munge binaries into their own namespace on disk
  • Containers namespace most aspects of the running binaries away from the default user space.

Early on, the Modularity WG decided not to focus on solving this problem yet again. Rather, they promoted and encouraged OCI containers, System Containers, and Flatpaks to address the different use cases in this space. Watch for another announcement about using System Containers with Boltron in a few weeks.

There are other solutions, but in the interest of time, the Working Group has focused on the other aspect, availability of multiple versions. At first glance, this may seem to be a simple problem. That is, until you review the Fedora infrastructure and see the tight coupling of our packaging and the concept of the “Fedora Release” (e.g. F25, F26, etc) with everything Fedora builds and ships.

The Working Group also took on the requirement to impact the Fedora Infrastructure, user base, and packager community as little as possible. The group also wanted to increase quality and reliability of the Fedora distribution, and drastically increase the automation, and therefore speed, of delivery.

As a result, the group didn’t treat this as a greenfield experiment that would take years to harden and trust. Instead, they kept the warts and wrinkles with the toolset, and implemented tools and procedures that slightly adjusted the existing systems to provide something new. Largely, the resultant package set can be thought of as virtualized, separate repositories. In other words, the client tooling (dnf) treats the traditional flat repo as if it was a set of repos that are only enabled when you want that version of the component.

Now Fedora has 25 modules for you to play with, easily shown with dnf module list or at the bottom of dnf list. As the Arbitrary Branching change to dist-git didn’t land in time for Fedora 26, the stream for most of the modules is the typical branch found in dist-git, namely f26. Over time, the modules are expected to actually develop their own streams that most likely follow their upstream communities. There is one example at present, where NodeJS version 8 is being made available in the nodejs-8 stream.

The Bits

“Blah blah, where are my bits,” you ask? The recommended process starts by running the system as a container, found in the Fedora Registry:

docker run --rm -it


The Modularity Working Group is interested in your feedback. The group developed a Getting Started page and a general feedback form. However, we could really use your specific feedback about the interactions with the tools and would love it if you could try our walk through.

You can find more general Modularity documentation, including how to build a module, at our docs site. The proposed Module Packaging Guidelines also appear in the Pagure repo, to ease collaboration before it is promoted to the Wiki after approval. We are recommending users try the container so that we have the opportunity to update it to deal with warts and feedback over the course of Fedora 26.