Bug 881894 - unit_copy dependency resolution should handle already satisfied dependencies
unit_copy dependency resolution should handle already satisfied dependencies
Status: CLOSED NOTABUG
Product: Pulp
Classification: Community
Component: rpm-support (Show other bugs)
Master
Unspecified Unspecified
low Severity unspecified
: ---
: ---
Assigned To: Michael Hrivnak
Preethi Thomas
: Triaged
Depends On:
Blocks: katello-v2-pulp
  Show dependency treegraph
 
Reported: 2012-11-29 13:27 EST by Justin Sherrill
Modified: 2013-11-01 14:57 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-11-01 14:57:29 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Justin Sherrill 2012-11-29 13:27:34 EST
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 15:43:59 EST
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 16:47:20 EDT
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 14:41:57 EDT
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 14:57:29 EDT
Actually this does appear to be fixed, yay!

Note You need to log in before you can comment on or make changes to this bug.