Frequently Asked Questions (FAQ)

Exactly what problem are you trying to solve?

Deploying software has many solutions, but what gets deployed often plays out as a fight between developers and operators. Developers want the latest (or at least later) features. Operators want software in packages, certified, with a known period of support. Fedora Modularity provides multiple versions of packages in a Linux distribution with the qualities expected from a Linux distribution: transparently built and delivered, actively maintained, and easy to install — making both happy.

How is this different from containers?

Containers are a solution to a very different problem. They allow you to bundle your application and all of its dependencies in a container image that you can run in isolation on basically any Linux system with a container runtime.

Modularity provides multiple versions of packages in a Linux distribution with the qualities expected from a Linux distribution: transparently built and delivered, actively maintained, and easy to install.

Modularity and containers work nicely together — since you need to get the software (such as your app’s dependencies) from somewhere. Getting them from a Linux distribution (and now with the choice of version thanks to Modularity) makes building and updating containers (with security updates for example) easier.

How does this differ from Software Collections (SCLs)?

SCLs use a different method of packaging allowing for multiple versions of the same piece of software to be installed on one system, by putting them into separate namespaced paths. Modularity on the other hand uses standard RPM packaging — so things are where you expect them to be — but you can only install one version at a time.

SCLs have proven to be hard to maintain and hard to use (Special macros in spec files, package name mangling, running 'scl enable' in order to make them visible). And the ability to install multiple versions in parallel has turned out not to be a common use case. The real benefit of SCLs was the ability to choose a specific version of software — and that’s exactly what Modularity offers.

Couldn’t we solve this with having compat packages, or putting versions into package names for different version streams?

That could work for some scenarios, however, it would introduce an unnecessary complexity to the whole system by adding even more packages to choose from. You would also need to encode information such as the major version (stream) in the package name, in a similar way how SCLs do that. How would you distinguish packages built against different versions of runtimes or other dependencies?

Modularity groups packages into modules — a representation of an application, a language runtime, or any logical group. That makes the content more granular and easier to navigate. Modules can be available in multiple streams — usually representing a major version of the software they ship.

Can I install more versions at once?

As modularity uses standard RPM packaging in order to install software in the usual places, the answer is no. However, there are other existing technologies — such as containers — allowing exactly that and work well with Modularity.

How is this different from RPM? Why not just different repos?

Modularity uses RPM as the core building block. From the user perspective, replacing modules with repositories could be technically possible, however:
A) Modules as a core concept in the client tooling significantly simplifies usage. Users can easily query for the modules available and install them with a simple command, without the need of manually enabling repositories.
B) From our perspective, a repository is a source of software provided by a vendor, not necessarily representing a single application. We want to keep this principal and allow multiple applications to be present in a repository.
C) Modularity also helps packagers to automatically submit multiple module builds at once based on their context configurations.

Are you going to produce all versions? What life cycles and versions are envisioned?

We are developing the technology such as the build pipeline and client tooling to enable contributors to build multiple versions. We envision longer life cycles of stacks mainly for server, and devel/rolling releases of some stacks for developers. However, contributors to the Fedora project will be the deciders and maintainers of any versions that are available.

I can just ‘dnf downgrade’ to get an older version.. Why do we need modularity?

Using an older version that is no longer maintained can be dangerous, mostly because of the lack of security updates. Modules, on the other hand, represent a major version that is still being actively maintained by the upstream and therefore should receive updates.

Is this different from single app VMs with custom versions?

This helps with a single app VM with custom versions. But instead of getting them from somewhere and maintaining them yourself, there is a good chance a module with the version you need already exists and is maintained — so you can just install it. Same as with containers, it helps users to get the right version for their system.