Are you going to produce all versions? What life cycles and versions are envisioned?
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.
Can I install more versions at once?
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. +
Couldn’t we solve this with having compat packages, or putting versions into package names for different version streams?
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.
Exactly what problem are you trying to solve?
Frequently Asked Questions (FAQ)
How does this differ from Software Collections (SCLs)?
How is this different from containers?
How is this different from RPM? Why not just different repos?
I can just ‘dnf downgrade’ to get an older version.. Why do we need modularity?
Is this different from single app VMs with custom versions?
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.
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. And technologies such as xref::architecture/stream-expansion.adoc[Stream Expansion] allow packagers to automatically build their module against multiple streams of runtimes, or entire Fedora releases — significantly lowering the manual effort. And for users, the client tooling is smart enough to choose the right combinations without exposing the underlying complexity by default — making it easier to use.
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 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 build dependencies, producing multiple combinations of binaries. And the client tooling then chooses the right binary when installing. See xref::architecture/stream-expansion.adoc[Stream Expansion] for more info.
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.
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. +