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/en-US/modularity/architecture/consuming/ 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/en-US/modularity/architecture/consuming/#_updating_the_system, Pulp should provide a dependency solving mechanism for the modular content, during the content--repository association workflow.
Pulp (@2.17) doesn't support inter-module dependencies when associating units recursively, neither does Pulp distinguish between modular and non-modular artifacts when recursively copying modules to a repository. Pulp however always copies all module artifacts, including the artifacts rpm dependencies. As a result, what gets copied over might render the target repository broken for a module consumer. Just in rare cases tho, one would hope O:-)
h2. Proposed solution
"Modules":https://docs.fedoraproject.org/en-US/modularity/architecture/ 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/en-US/modularity/architecture/consuming/#_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.
Modules have a concept of "installation profile":https://docs.fedoraproject.org/en-US/modularity/architecture/consuming/#_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/en-US/modularity/making-modules/defining-modules/#_advanced_dependencies_optional, either for the build- or the run-time.
To support these usecases, a fake @libsolv@ solvable can be created for each module unit. This will allow tracking dependencies between the modules. To prevent non-modular content from satisfying dependencies in target repository, it seems exposing the @pool->considered@ bitmap from the @libsolv@ library to its Python binding will be required. This is how DNF deals with solving modular dependencies when installing and upgrading content. This effort is tracked in the sub-task #3741.
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
* "modular errata":https://pulp.plan.io/issues/3919
.