Bug 881894

Summary: unit_copy dependency resolution should handle already satisfied dependencies
Product: [Retired] Pulp Reporter: Justin Sherrill <jsherril>
Component: rpm-supportAssignee: Michael Hrivnak <mhrivnak>
Status: CLOSED NOTABUG QA Contact: Preethi Thomas <pthomas>
Severity: unspecified Docs Contact:
Priority: low    
Version: MasterCC: jason.dobies, jsherril, mhrivnak
Target Milestone: ---Keywords: Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-11-01 18:57:29 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 854726    

Description Justin Sherrill 2012-11-29 18:27:34 UTC 
Description of problem:

For katello it would be ideal for unit_copy's rpm dependency resolution to behave more like yum in that:

- if a dependency is already defined in the destination repo (or in the unit_copy trasnactional set), no additional units are copied
-  else copy the latest package that satisfies the dependency



Previously in pulpv2 all packages that matched a dependency were copied, and I belive now the newest is always copied.  Neither of these are ideal, and i think most users would expect a yum like behavior.
Comment 1 Jay Dobies 2013-01-31 20:43:59 UTC 
This is non-trivial to do given the yum APIs we're using. We're about to begin work on ripping out yum in favor of a home grown solution for performance and flexibility reasons. As part of that, I could see us having to do our own version of dep solving to remove the need for generated repo metadata on disk.

Where I'm going with this is that I want to punt it off until that solution starts to take shape. I think it'll be significantly easier and perform better than trying to shoe horn this into the yum APIs.
Comment 87 Michael Hrivnak 2013-08-02 20:47:20 UTC 
I think the new importer in 2.2 does this. It assumes that if a package is already in the destination repo, some other operation has already taken care of its dependencies.

Can the OP please verify if this is still a bug?
Comment 88 Justin Sherrill 2013-11-01 18:41:57 UTC 
So I don't think this is already covered necessarily, Notice in my original comment, i mentioned 'dependency' not package.

- if a dependency is already defined in the destination repo (or in the unit_copy trasnactional set), no additional units are copied
-  else copy the latest package that satisfies the dependency


For example, if foo requires bar, and in the source repo we have:

bar-1.0
bar-2.0
bar-3.0 

and in the destination repo we already have

bar-1.0,

the dependency resolution would copy bar-2.0 and bar-3.0 into the destination repo.  It would also copy all packages that satisfy all dependencies for bar-2.0 and bar-3.0.

I will re-test to confirm though.
Comment 89 Justin Sherrill 2013-11-01 18:57:29 UTC 
Actually this does appear to be fixed, yay!