Story #3740

Updated by ttereshc almost 2 years ago

h2. Motivation

In order for the user to be able to "consume modular content": provided by Pulp, while still enabling the Pulp administrator to copy modular content, including it's dependencies, between repositories, repositories and, at the same time, adhering to the "expected modular content upgrade semantics":, Pulp should provide a dependency solving mechanism for the modular content, during the copy operation. content--repository association workflow.

Pulp (@2.18) ignores module (@2.17) doesn't support inter-module dependencies when copying modules recursively.
associating units recursively, neither does 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
In a rare case:
case --- there has to be a mixture of modular and non-modular packages with the same NEVRA are present in a repo
name and unlucky coincidence with versions
- as a result - a "bad" repo (client will likely have a
version for the problem with to happen --- what gets copied over might render the target repository broken for a module which doesn't have all its *modular* rpms in a repo, since some of the copied rpms were non-modular ones). consumer.

h2. Proposed solution

It's important for modules "Modules": are content units, that ship RPM content with respect to have all their artifacts present in a repo.
No matter
declared policy, such as backwards compatibility. For this reason, resolving dependencies of a module is slightly different than that of the depsolving strategy generic RPM content, especially and unlike described in the "Support more conservative dependency solving": for RPMs, *all* module artifacts should be copied to a target repo together with a module. E.g RPM units, "the preference of the content dependency version goes within the module": 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": 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":, 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":
* the depsolving library investigation #3528 "POC":
* "libsolv":
* "modular errata":
* A cross-team, "modular-depsolving document":