Context
When managing curated RPM repositories, a common workflow is to copy a subset of packages from a source repository (e.g., an upstream AlmaLinux mirror) into a destination repository that is maintained over time. As the source repository is updated with newer package builds, operators want to be able to refresh their destination repository so that dependencies are resolved to the latest available versions rather than keeping older ones already present.
Problem
The current copy API uses SOLVER_FLAG_FOCUS_INSTALLED by default, which causes the dependency solver to prefer package versions already present in the destination repository. This is the correct behavior for incremental updates, but it prevents operators from refreshing dependencies to their latest versions when explicitly desired.
For example: if the destination already contains openssl-libs-3.5.1-3 and the source has openssl-libs-3.5.1-7, copying a package that depends on openssl-libs will keep the old -3 build even though a newer compatible build is available.
Proposed Solution
Add a dependency_upgrade boolean field to the copy API (default false, preserving existing behavior). When set to true, the solver is configured with SOLVER_FLAG_FOCUS_INSTALLED=0 and SOLVER_FLAG_FOCUS_BEST=1, causing it to resolve transitive dependencies to the latest available version in the source repository instead of preferring what is already installed in the destination.
Context
When managing curated RPM repositories, a common workflow is to copy a subset of packages from a source repository (e.g., an upstream AlmaLinux mirror) into a destination repository that is maintained over time. As the source repository is updated with newer package builds, operators want to be able to refresh their destination repository so that dependencies are resolved to the latest available versions rather than keeping older ones already present.
Problem
The current copy API uses SOLVER_FLAG_FOCUS_INSTALLED by default, which causes the dependency solver to prefer package versions already present in the destination repository. This is the correct behavior for incremental updates, but it prevents operators from refreshing dependencies to their latest versions when explicitly desired.
For example: if the destination already contains openssl-libs-3.5.1-3 and the source has openssl-libs-3.5.1-7, copying a package that depends on openssl-libs will keep the old -3 build even though a newer compatible build is available.
Proposed Solution
Add a dependency_upgrade boolean field to the copy API (default false, preserving existing behavior). When set to true, the solver is configured with SOLVER_FLAG_FOCUS_INSTALLED=0 and SOLVER_FLAG_FOCUS_BEST=1, causing it to resolve transitive dependencies to the latest available version in the source repository instead of preferring what is already installed in the destination.