Story #3740
Updated by milan over 6 years ago
h2. Motivation
In order for the user to be able to "consume modular content":https://docs.fedoraproject.org/fedora-project/subprojects/fesco/en-US/architecture/Consuming_Software.html provided by Pulp, while still enabling the Pulp administrator to copy modular content, including it's dependencies, between repositories and, at the same time, adhering to the "expected modular content upgrade semantics":https://docs.fedoraproject.org/fedora-project/subprojects/fesco/en-US/architecture/Consuming_Software.html#updating-the-system, Pulp should provide a dependency solving mechanism for the modular content, during the content--repository association workflow.
h2. Proposed solution
As shown in the issue #3528 "POC":https://github.com/dparalen/pulp_solv the @libsolv@ library can be used to resolve dependency queries for the general recursive, content copy use case.
"Modules":https://docs.fedoraproject.org/fedora-project/subprojects/fesco/en-US/architecture/Main_Concepts.html#modules-and-streams are content units, that ship RPM content with respect to a declared policy, such as backwards compatibility. For this reason, resolving dependencies of a module is slightly different than that of the generic RPM content, especially and unlike described in the "Support more conservative dependency solving":https://pulp.plan.io/issues/2478 for RPM units, "the preference of the content dependency version goes within the module":https://docs.fedoraproject.org/fedora-project/subprojects/fesco/en-US/architecture/Consuming_Software.html#updating-the-system i.e in case the target repository already contains units newer than a module requires, the module-required units need to be copied in the older version, in addition to the already present units.
To support this use case, it seems exposing the @pool->considered@ bitmap from the @libsolv@ library to its Python binding will be required. This effort is tracked in the sub-task #3741.
Modules have a concept of "installation profile":https://docs.fedoraproject.org/fedora-project/subprojects/fesco/en-US/architecture/Consuming_Software.html#installation-profile that e.g addresses mutual compatibility of client and server software by shipping them together. Selectively copying just a subset of these profiles would break the purpose of the profiles. Therefore, Pulp should copy all the profiles of a module all the time.
"Modules may depend on other modules":https://docs.fedoraproject.org/fedora-project/subprojects/fesco/en-US/making-modules/Defining_Modules_in_Modulemd.html#depending-on-other-modules, either for the build- or the run-time.
h2. Open questions
A question reminds how errata should be handled in the context of a module.
Based on the "main concepts of modularity":https://docs.fedoraproject.org/fedora-project/subprojects/fesco/en-US/architecture/Main_Concepts.html it might seem that a module behaves as an immutable container of content.
Therefore it might seem errata should refer to a module as a whole rather than to its rpms but that's left to be investigated.
h2. References
* the base pulp_modularity support tracker; Issue #3206
* the "Modularity project docs page":https://docs.fedoraproject.org/fedora-project/subprojects/fesco/en-US/index.html
* the depsolving library investigation #3528 "POC":https://github.com/dparalen/pulp_solv
* "libsolv":https://github.com/openSUSE/libsolv
.