pulp
pulp_rpm doesn't allow packages with different filenames but same NEVRA+checksum
Describe the bug We've encountered problems due to the fact that packages with the same NEVRA+checksum but different filenames can't exist in pulp_rpm. It looks like pulp_rpm is using NEVRA + checksum as the unique constraint for packages.
One problem scenario: a package with a given filename is synced into pulp and now other repos are forced to use this package filename. It looks like the unique constraint is being used by the sync code here to know if it already has the package. So the package gets synced into Pulp and then other repos that may have the package named differently in their remotes end up with the other package name.
To Reproduce
cd /tmp
mkdir repo1 repo2
cd repo1
wget https://fixtures.pulpproject.org/rpm-unsigned/bear-4.1-1.noarch.rpm
createrepo .
pulp rpm remote create --name remote1 --url "file://$(pwd)"
pulp rpm repository create --name repo1 --remote remote1
cd ../repo2
cp ../repo1/bear-4.1-1.noarch.rpm bare-4.1-1.noarch.rpm # bad filename
createrepo .
pulp rpm remote create --name remote2 --url "file://$(pwd)"
pulp rpm repository create --name repo2 --remote remote2
Now if you sync repo 2 first, then the bare-4.1-1.noarch.rpm package wins and all repos containing the bear package will now have bare-4.1-1.noarch.rpm.
Expected behavior I'd probably argue that Pulp should maintain the location_href from upstream and thus, one solution would be to include the location_href or relative_path in the unique constraint. In fact, pulp_deb does this.
I'd just add that it's not necessarily a matter of good and bad package names. Different repos might be owned by different teams and want to use different filenames for the same package. Right now this is impossible in pulp_rpm, and not just in relation to syncing, because attempting to create two Packages with different filenames but the same NEVRA+Checksum would violate the db unique constraint.
@sdherr thanks I actually uploaded the packages and confirmed that Pulp only stores one. I've attempted to generalize this issue.