fedora-docs / modularity

Clone
Source Code
GIT

#81 Added glossary page
Closed 3 years ago by mcurlej. Opened 3 years ago by mcurlej.
fedora-docs/ mcurlej/modularity glossary  into  master

file modified
+1 
@@ -1,6 +1,7 @@ 
 

  * **What is Modularity**
 

  * xref:index.adoc[Introduction]
 

  * xref:community.adoc[Community]
 

+ * xref:glossary.adoc[Glossary]
 

  * xref:architecture.adoc[Core Concepts]
 

  ** xref:architecture/building.adoc[Building Software]
 

  ** xref:architecture/consuming.adoc[Consuming Software]

file modified
+1 -1 
@@ -12,7 +12,7 @@ 
 

  

  == Source-level module ID (NSV)
 

  

- At the source level, modules are only identified by the first three: _name_, _stream_, and _version_. Name is defined as a name of the module’s repository in https://src.fedoraproject.org/[DistGit], stream is a name of the branch in https://src.fedoraproject.org/[DistGit], and version is the timestamp of a commit.
 

+ At the source level, modules are only identified by the first three: _name_, _stream_, and _version_. Name is defined as a name of the module’s repository in https://src.fedoraproject.org/[DistGit^], stream is a name of the branch in https://src.fedoraproject.org/[DistGit^], and version is the timestamp of a commit.
 

  

  === Name

file added
+46 
@@ -0,0 +1,46 @@ 
 

+ = Glossary
 

+ 

+ As Modularity introduces a lot of new terms to the packaging environment, here you can find a small glossary for a quick introduction to the topic. 

+ 

+ 1. **<<Modularity>>**
 

+ 2. **<<Module>>**
 

+ 3. **<<Module Stream (Application Stream)>>**
 

+ 4. **<<Default Module Stream>>**
 

+ 5. **<<Module Artifact>>**
 

+ 6. **<<Module Stream Expansion>>**
 

+ 7. **<<Module Metadata>>**
 

+ 8. **<<NSVCA>>**
 

+ 9. **<<Modular Repository>>**
 

+ 10. **<<Upgrade Path>>**
 

+ 

+ == Modularity
 

+ It’s a technology which is built on top of the standard rpm ecosystem. It enables you to create modular repositories which contain software which is built/bundled differently then the one available in an operating system release i. e. enables you to provide older/newer major versions of software to be available in one operating system release for example.

This is very hard to grasp. So it' a technology, on top of rpm. The rest is gibberish to me, sorry. It's built differently? So it is RPM, or not? It enables to have older/newer major versions of software available? How, RPM supports that out of the box.

Not on top of RPM, but the standard RPM ecosystem. Maybe standard packaging ecosystem would be better? wrt to different builds, yes with modules you can have software in packages which is build with different features then the one available in OS release.

 
+ 

+ == Module
 

+ Module is not a RPM. Module is a group of software defined in the Modularity ecosystem. It does not represent a specific “flavor” but all of the “flavors” of the given software in an operating system release i. e. it is a group of all the different “flavours” of the software represented by its name.

@churchyard It is explicitly stated that Module is not a RPM.

The definition of a module ignores nonmodular "flavors" of the software.

 
+ 

+ == Module Stream (Application Stream)
 

+ Stream is a unit of software defined in the Modularity ecosystem. represents a specific “flavour” of a software. This means different major versions of the software or a different build of the software. The name of the stream is normally represented by the SVC branch of the given software in https://src.fedoraproject.org/[disgit^].

different build -> different build configuration?

SVC -> CVS?

 
+ 

+ == Default Module Stream
 

+ It's a special stream which is installed if you don’t specify a stream when installing a module. Not all modules have default streams as it is not mandatory.

If only this was the only thing default stream actually is :( The fact that default streams are automatically enabled even if users don't opt in for modules might be worth mentioning in here.

 
+ 

+ == Module Artifact
 

+ The result of a module build is a module artifact. The artifact is represented by a directory which contains metadata files which define the module stream and one or more rpms which contain the software which this module stream represents.

So one directory with multiple metadata and one or more rpm is a single artifact? This is confusing.

 
+ 

+ == Module Stream Expansion
 

+ Stream expansion is additional metadata you can specify in your modulemd file. The metadata specifies how and for what major releases of an operating system, your package will be built.

I've had the impression "Stream expansion" is a feature, not metadata.

 
+ i. e. you can specify that mariadb:10 can be built for f29, f30, f31 and not built for f28 with specific options for each buildroot.  

+ 

+ == Module Metadata
 

+ Metadata which defines how a module should look like. It defines how and for what releases the module should be built and how it will look like after the build process is finished and how it will be installed.

So "Modular Meatdata" are "source", not "artifact"? E.g. they only describe the module/stream before it is built?

 
+ The module metadata is stored in yaml format according to https://github.com/fedora-modularity/libmodulemd/tree/master/yaml_specs[modulemd specification^].
 

+ 

+ == NSVCA
 

+ This abbreviation describes the new naming conventions for modular packages i. e. Name:stream:version:context:architecture. For more information see this xref:nsvca.adoc[section].
 

+ 

+ == Modular Repository
 

+ Is a directory which holds all the artefacts which are produced by the build process of a module. Each module produces one directory.

So it's juts a directory? Where is the "repository" part? Also, all different streams of one module are in one directory?

 
+ 

+ == Upgrade Path
 

+ A virtual path which describes with what patch a software should be updated. For example, dnf resolves those paths when we update our software with dnf update command.

with what patch? No idea what you try to say here.

As modularity introduces a lot of new technical terms into the existing
packaging environment, a glossary page has been added to serve as a quick
reference to Modularity

Issue: modularity#174

Signed-off-by: Martin Curlej mcurlej@redhat.com

@frostyx @dmach @churchyard

This is very hard to grasp. So it' a technology, on top of rpm. The rest is gibberish to me, sorry. It's built differently? So it is RPM, or not? It enables to have older/newer major versions of software available? How, RPM supports that out of the box.

@churchyard It is explicitly stated that Module is not a RPM.

Not on top of RPM, but the standard RPM ecosystem. Maybe standard packaging ecosystem would be better? wrt to different builds, yes with modules you can have software in packages which is build with different features then the one available in OS release.

yes with modules you can have software in packages which is build with different features then the one available in OS release.

You can have this with custom shell scripts as well.

yes with modules you can have software in packages which is build with different features then the one available in OS release.

You can have this with custom shell scripts as well.

Not sure what is your point? This PR is not comparing what other technologies can also do. This should be only a quick summary of the technology. I am open tu suggestions if you have a better description.

The definition of a module ignores nonmodular "flavors" of the software.

The definition of a module ignores nonmodular "flavors" of the software.

Thanks will change that.

Not sure what is your point?

My point is that the modularity term is not well defined. It's confusing. No, I don't have better suggestions. I don't actually know what modularity is. Maybe we can define it using all the other terms? Modularity is a projects that enables creating and consuming alternate versions or flavors of RPM packaged software via so called modules (defined below).

different build -> different build configuration?

SVC -> CVS?

If only this was the only thing default stream actually is :( The fact that default streams are automatically enabled even if users don't opt in for modules might be worth mentioning in here.

So one directory with multiple metadata and one or more rpm is a single artifact? This is confusing.

I've had the impression "Stream expansion" is a feature, not metadata.

So "Modular Meatdata" are "source", not "artifact"? E.g. they only describe the module/stream before it is built?

So it's juts a directory? Where is the "repository" part? Also, all different streams of one module are in one directory?

with what patch? No idea what you try to say here.

Sorry, but generally, I don't find the definitions good. I know a lot of stuff about modularity, but I don't understand the terms as described here. try showing the glossary to somebody who doesn't know it already and ask them to explain it back in their own terms.

(Maybe we should do this in a shared Google Document and open a PR after? Pagure is extremely not good for in-diff discussion.)

Pull-Request has been closed by mcurlej
3 years ago
Metadata
None
No Tags
Changes Summary 3
+1 -0
file changed
modules/ROOT/nav.adoc
+1 -1
file changed
modules/ROOT/pages/architecture/nsvca.adoc
+46
file added
modules/ROOT/pages/glossary.adoc
Powered by Pagure 5.13.3
Documentation • File an Issue • About • SSH Hostkey/Fingerprint
© Red Hat, Inc. and others.