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 content goes within the model":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 declared version.
To support this use case, it seems exposing the @pool->considered@ bitmap from the @libsolv@ library to its Python binding is required. This effort is tracked in a separate sub-task.
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. 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
.