Bug 881894 - unit_copy dependency resolution should handle already satisfied dependencies
Summary: unit_copy dependency resolution should handle already satisfied dependencies
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Pulp
Classification: Retired
Component: rpm-support
Version: Master
Hardware: Unspecified
OS: Unspecified
low
unspecified
Target Milestone: ---
: ---
Assignee: Michael Hrivnak
QA Contact: Preethi Thomas
URL:
Whiteboard:
Depends On:
Blocks: katello-v2-pulp
TreeView+ depends on / blocked
 
Reported: 2012-11-29 18:27 UTC by Justin Sherrill
Modified: 2013-11-01 18:57 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-11-01 18:57:29 UTC


Attachments (Terms of Use)

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!


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