From 36800e3e2139cf74329a69906228704554326486 Mon Sep 17 00:00:00 2001 From: Adam Samalik Date: Nov 21 2018 13:58:06 +0000 Subject: fix minor typos --- diff --git a/modules/ROOT/pages/faq.adoc b/modules/ROOT/pages/faq.adoc index 190b8ba..3a709f6 100644 --- a/modules/ROOT/pages/faq.adoc +++ b/modules/ROOT/pages/faq.adoc @@ -20,14 +20,14 @@ How does this differ from Software Collections (SCLs)?:: 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. And technologies such as xref::architecture/stream-expansion.adoc[Stream Expansion] allow packagers to automatically build their module against multiple streams of runtimes, or the whole 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 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. 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 quiery for the modules available and install them with a simple command, without the need of manually enabling repositories. + + 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 depencies, 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. + 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. 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.