Story #3740
Updated by ttereshc over 5 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 lacks ability administrator to perform copy modular content, including it's dependencies, between repositories, Pulp should provide a dependency solving at a module level and mechanism for the modular content, during the copy operation to copy not only artifacts but dependent modules and their artifacts as well. operation. Pulp (@2.18) ignores module dependencies when copying modules recursively. Pulp doesn't 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. A potential problem and a rare case: - a mixture of modular and non-modular packages with the same NEVRA are present in a repo - unlucky coincidence with versions - as a result - a "bad" repo (client will likely have a problem with a module which doesn't have all its *modular* rpms in a repo, since some of the copied rpms were non-modular ones). h2. Proposed solution It's important for modules to have all their artifacts present in a repo. No matter of the depsolving strategy for RPMs, *all* module artifacts should be copied to a target repo together with a module. E.g 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 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. Pulp should perform dependency solving based on runtime dependencies only. They are already available on Modulemd model. <<< --- needs review/rewrite 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 * A cross-team, "modular-depsolving document":https://docs.google.com/document/d/1U-kkciwohRTuTF12V-uc0TrIrm0YDQxpqtD3feJJANo/edit
.