Bug 1098703

Summary: Having multiple packages with the same NVREA results in broken repos.
Product: [Retired] Pulp Reporter: Justin Sherrill <jsherril>
Component: rpm-supportAssignee: pulp-bugs
Status: CLOSED DUPLICATE QA Contact: pulp-qe-list
Severity: unspecified Docs Contact:
Priority: medium    
Version: 2.4.0CC: gassmann, ipanova, skarmark
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: 2015-01-07 14:58:41 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:

Description Justin Sherrill 2014-05-17 13:15:50 UTC
Description of problem:

I've seen many users have this problem with pulp and have helped a user in #pulp with it before too.

If two packages get added to a repo with the same Name-version-release-epoch-arch pulp will gladly add them to the repo.  When the repo is published both are added to the primary.xml file but only one rpm is symlinked in the actual repo. 

So yum comes along and randomly chooses one of the two rpms in the primary.xml (probably either first or last), and attempts to download the rpm.  Depending on which one actually got published to the repo the rpm may or may not match the entry yum selected in the primary.xml

'[Errno -1] Package does not match intended download'

In most all cases the user doesn't realize that there are duplicates, as this has occurred from some upstream repo.


Version-Release number of selected component (if applicable):

Seen in pulp 2.3.

How reproducible:


Steps to Reproduce:
1.  push two packages with the same NVREA to a repo
2.  Have a client try to install one of those packages


Actual results:
'[Errno -1] Package does not match intended download'

Expected results:

I could see a couple of possibilities here:

1)  when syncing or rpm pushing, replace the rpm in the repo with the current one and throw a warning.
2)  when syncing or rpm pushing, ignore the duplicates and throw a warning.
3)  When publishing trim the repo packages list (in memory) to only unique rpms before writing the metadata and symlinking the rpms

I'd probably prefer 3 of all of those.

Comment 1 Ina Panova 2015-01-07 14:58:41 UTC

*** This bug has been marked as a duplicate of bug 1132659 ***