Project

Profile

Help

Story #3740

closed

Implement modularity content dependency solving

Added by milan over 6 years ago. Updated over 5 years ago.

Status:
CLOSED - CURRENTRELEASE
Priority:
Normal
Assignee:
Sprint/Milestone:
Start date:
Due date:
% Done:

100%

Estimated time:
(Total: 0:00 h)
Platform Release:
2.19.0
Groomed:
No
Sprint Candidate:
No
Tags:
Pulp 2
Sprint:
Sprint 47
Quarter:

Description

Motivation

Pulp lacks the ability to perform dependency solving at a module level and to copy dependent modules and their artifacts during copy 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).

Proposed solution

It's important for modules to have all their artifacts present in a repo.
Regardless of the depsolving strategy for RPMs, all module artifacts and related modules should be copied to a target repo. E.g if 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.

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.

References


Sub-issues 1 (0 open1 closed)

Task #3746: Investigate, whether exposing the @pool->considered@ bitmap is necessary for the modular dependencies to be resolvedCLOSED - COMPLETE

Actions

Related issues

Related to RPM Support - Story #4058: As a user, I can calculate applicability for modular contentCLOSED - CURRENTRELEASEttereshc

Actions
Related to RPM Support - Issue #4152: Regression Pulp 2.17.1: recursive copy of RPMs does not copy partially resolvable dependenciesCLOSED - CURRENTRELEASEmilanActions
Related to RPM Support - Story #4162: As a user, I have dependency solving when copying modulesCLOSED - CURRENTRELEASEdalley

Actions
Related to RPM Support - Test #4543: Test newly described definitions of recursive and recursive_conservative flagsCLOSED - COMPLETEbherringActions
Copied to RPM Support - Test #4364: Implement modularity content dependency solvingCLOSED - COMPLETEbherringActions

Also available in: Atom PDF