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.