Frequently Asked Questions (FAQ)

Exactly what problem are you trying to solve?

The “too fast vs. too slow” problem, outdated containers, and complex packaging workflow. See The Problem to be Solved page for more detailed information.

How is this different from containers?

This is a build step that happens before containers. Modularity provides parallel availability of multiple versions that can be consumed by containers to enable parallel installation.

How does this differ from Software Collections (SCLs)?

Modularity is about building multiple versions of packages, and making them all available to users. SCLs are about installing software in parallel using RPM. These two don’t overlap, they complement each other. You can build a Modular SCL.

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

That works technically, but the packaging workload doesn’t scale, and dependency interactions become complex. This will let packagers make more content available to users without an explosion of effort. Modules also help to solve the discoverability problem. For example, is httpd v2.4 in a package called httpd-2-4 or http-2?

Can I install more versions at once?

Modularity does not invent a new technology for parallel installation. Existing solution such as containers or Software Collections can be used to achieve this.

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

Technical: DNF performance with many repositories. We envision having tens or even hundreds of modules available to a single system.
User experience: A repository is a source of software provided by a vendor, not necessarily representing a single application, language stack, or any other logical unit of software. A repository typically contains multiple applications, stacks, etc. We do not want to change this concept.

Are you going to produce all versions? What lifecycles 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 lifecycles 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. Same as with containers, it helps users to get the right version for their system.