Story #3740

Updated by dalley almost 2 years ago

h2. Motivation

Pulp lacks ability to perform dependency solving at a module level and during copy operation to copy not only artifacts but dependent modules and their artifacts as well.

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":, either for the build- or the run-time. Pulp should perform dependency solving based on runtime dependencies only. They are already available on the 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":
* the depsolving library investigation #3528 "POC":
* "libsolv":
* "modular errata":
* A cross-team, "modular-depsolving document":