Summary

The tools/osbuild-mpp tool contains its own DNF depsolver implementation (DepSolver class) that duplicates functionality already present in osbuild/solver/dnf.py and osbuild/solver/dnf5.py.

Problem

• Code duplication: The DepSolver class in osbuild-mpp reimplements DNF-based dependency resolution that already exists in the osbuild.solver module.
• Maintenance burden: Bug fixes and improvements need to be applied in multiple places.
• Feature parity: The osbuild.solver module supports both DNF4 and DNF5 backends, while osbuild-mpp only supports DNF4.
• Inconsistency: Different code paths for the same operation may lead to subtle behavioral differences.

Desired Outcome

• Remove the custom DepSolver implementation from tools/osbuild-mpp.
• Refactor osbuild-mpp to use the existing osbuild.solver.DNF and osbuild.solver.DNF5 implementations.
• Allow users to choose between DNF4 and DNF5 solvers via the existing manifest-level "solver" key in the mpp-depsolve block (e.g., "solver": "dnf" or "solver": "dnf5").
• Preserve the current default behavior ("dnf") to maintain backward compatibility.

Current Approach

The solver type is currently configured per-manifest in the mpp-depsolve block:
"mpp-depsolve":

 
The DepSolverFactory.get_depsolver() method selects the solver based on this value, defaulting to "dnf" if not specified. This same approach should be preserved when switching to the osbuild.solver implementations.

Current State

• tools/osbuild-mpp: Custom DepSolver class (~150 lines) using dnf directly
• osbuild/solver/dnf.py: Full-featured DNF solver class
• osbuild/solver/dnf5.py: Full-featured DNF5 solver class

Upstream issue: https://github.com/osbuild/osbuild/issues/2281