Story #4049
Updated by ipanova@redhat.com about 6 years ago
All modular RPMs have DISTTAG tag (not to be confused with the %{dist} tag) set to the module they have been built for.
<pre>
>>> headers[rpm.RPMTAG_DISTTAG]
'module(nodejs:10:20180813130636:9edba152)'
</pre>
Presence of 'module(...)' indicates that an RPM is a modular one.
Detailed info (NSVC) about a module the RPM was built for is not reliable and can't be used to identify the module the RPM belongs to. The NSVC indicates which module that RPM was built for originally, but the same RPM can potentially be used in different modules and the DISTTAG won't be updated.
Pulp needs this information to perform reliable filtering of modular RPMs.
This is required for applicability calculation.
It can also be helpful for:
* checking module consistency
* finding modular RPMs
* upload of modular RPMs if/when Pulp needs to create a reference to a module
Suggested solution:
Add a new field "modular" to the RPM model which will indicate if RPM is modular or not.
In case of on_demand sync, RPM headers can't be analysed, analyzed, so the "modular" field can be set only by analyzing modules metadata in modules.yaml file. For all its artifacts, "modular" field should be set to True. We will rely on the repodata information provided in the modules.yaml during sync whether policy is immediate or on_demand.
In case of upload, a DISTTAG tag from header can be used as described above.
Migration is needed. "modular" filed can be set by analysing analyzing existing modules in Pulp. In case there are modular RPMs in Pulp which don't belong to any module, the "modular" flag would be set incorrectly. At this moment the likelihood of that is low:
* there are no production bits for modularity content at the moment, only F29 beta content.
* if module is removed from Pulp, its artifacts/RPMs are removed as well.
.