Project

Profile

Help

Story #3740

Updated by dalley about 4 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":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 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":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 

Back