Hide Forgot
We currently label modular RPM builds by filling the DistTag header field. However, it turns out this field isn't entirely unused: https://pagure.io/modularity/issue/113 https://github.com/rpm-software-management/rpm/issues/589 Therefore we would like to add a new field for our purposes, ensuring we don't run into similar conflicts in the future. We use this as a bool to tell modular and non-modular builds apart when the repodata isn't available but we also use it to store the original module NSVC for accountaing purposes. I think ModuleTag would be a reasonable name for this. Please, also ensure we can set this field for both binary and source RPM builds, preferrably via %{moduletag}. We also need to be able to query this.
Remind me, why can't we use provides?
(In reply to Igor Gnatenko from comment #1) > Remind me, why can't we use provides? Short answer: we can't set Provides on the SRPM creation or for subpackages that contain zero files (metapackages), because the automatic dependency generators don't run.
That's one thing that could be fixed. However, since we'll want RPM to work with this information later, a header field makes more sense. We also have no need for this in the repodata and don't want to pollute the provides for no real reason.
Please come up with a more specific name, "module" is such a generic and widely used term. For example "modularity", "modular" or "modulemd" (append Tag if you like) would help point towards the Modularity effort rather than the generic concept of modules which are everywhere, including but not limited to kernel.
Ah, thought you were against just the word "module" on its own. Considering your suggestion, would ModularBuild make sense to you? It kinda feels like a bool and since we store the build NSVC in there, it could work.
ModularBuild sounds excellent for the purpose.
Great, let's go with that!
> NSVC What is this? I get name:stream-version, but what's "C"?
(In reply to Neal Gompa from comment #8) > > NSVC > > What is this? I get name:stream-version, but what's "C"? C is "context". It's a disambiguation between two module streams that are the same except for their dependencies. (For example, let's say I build a webapp that is compatible with either Node.js 8.x or 10.x. We'd build two versions of webapp:stream, one for 8.x and one for 10.x and differentiate them with 'context'. Then, e.g if there were other module streams on the system that could only use nodejs:8, DNF would select the context of the webapp:stream that works with that version of nodejs.
Yes, mostly true. Although it's not strictly about runtime dependencies, it's about distinguishing builds built in different buildroots (different platforms, different combinations of modular deps) -- this might or might not affect the runtime deps, but it usually does.
Can we get an ETA on this?
Almost forgot the Fedora side of this, but waken up by the disttag-discussion on fedora-devel: the upstreamed modularitylabel tag backported to Fedora as of rpm-4.14.2.1-4.fc30.
Clear needinfo