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.)