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/ 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/en-US/modularity/architecture/consuming/#_updating_the_system, 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. 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. h2. Proposed solution As a result, what gets copied over might render shown in the target repository broken issue #3528 "POC":https://github.com/dparalen/pulp_solv the @libsolv@ library can be used to resolve dependency queries for a module consumer. the general recursive, content copy use case. h2. Proposed solution "Modules":https://docs.fedoraproject.org/en-US/modularity/architecture/ "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/en-US/modularity/architecture/consuming/#_updating_the_system 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/en-US/modularity/architecture/consuming/#_installation_profile 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/en-US/modularity/making-modules/defining-modules/#_advanced_dependencies_optional, 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. To support these usecases, a fake @libsolv@ solvable can h2. Open questions A question reminds how errata should be created for each module unit. This will allow tracking dependencies between the modules. To prevent non-modular content from satisfying dependencies handled in target repository, it seems exposing the @pool->considered@ bitmap from context of a module. Based on the @libsolv@ library "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 Python binding will rpms but that's left to 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. 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 * "modular errata":https://pulp.plan.io/issues/3919
.