Project

Profile

Help

Maintenance: Planio will be observing a scheduled maintenance window this Tuesday, November 5, 2024 from 03:00 UTC until 06:30 UTC to perform urgent network maintenance in our primary data center. Your Planio account will be unavailable during this maintenance window.

Story #2478

closed

Support more conservative dependency solving

Added by jsherril@redhat.com almost 8 years ago. Updated over 5 years ago.

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

100%

Estimated time:
Platform Release:
2.17.0
Groomed:
Yes
Sprint Candidate:
Yes
Tags:
Pulp 2
Sprint:
Sprint 40
Quarter:

Description

Description

Given two repositories:

Repository A with packages:
Foo-1.0
Foo-2.0
Foo-3.0
Bar-1.0
Repository B with packages:
Foo-1.0

And assuming Bar-1.0 requires Foo >= 1.0.

As i understand it, if a user performs a unit copy of Bar-1.0 from Repository A into Repository B with dependency resolution turned on (recursive = true), currently it will copy all packages from Repository A into Repository B that satisfies all of Bar-1.0's dependencies. In this example that would mean Foo-2.0, and Foo-3.0 are both copied to Repository B despite the fact that all of Bar-1.0's dependencies are already met in Repository B.

I think (and i think users would agree), that this should behave more like a 'yum install Foo-1.0' or a 'yum update Foo-1.0', in that it should only pull in dependencies that are actually needed by a client to install Bar-1.0 if they are not already in the target repository. So in this example the unit copy would only pull in Bar-1.0 and no additional dependencies.

Implementation

The PR https://github.com/pulp/pulp_rpm/pull/1122 implements the described behavior, having the libsolv solver consider the target repository content.

An optional, future (Pulp3) behavior of actually upgrading the content in the target repository under the same circumstances i.e the opposite behavior, can be enforced by providing the solver a job constructed with the solv.Job.SOLVER_UPDATE flag in addition to the current solv.Job.SOLVER_INSTALL flag, possibly exposing this thru a REST API post request body field.


Related issues

Related to RPM Support - Story #3715: Reimplement unit dependency solving with the libsolv libraryCLOSED - CURRENTRELEASEmilan

Actions

Also available in: Atom PDF