Bug 1134364
Summary: | Pulp yum repos are not working correctly when adding to a repo-product-CV a RPM package with name exactly equal to an already existing package (but with different content) | |||
---|---|---|---|---|
Product: | Red Hat Satellite | Reporter: | Benjamin Chardi <bchardim> | |
Component: | Pulp | Assignee: | satellite6-bugs <satellite6-bugs> | |
Status: | CLOSED WONTFIX | QA Contact: | Katello QA List <katello-qa-list> | |
Severity: | medium | Docs Contact: | ||
Priority: | unspecified | |||
Version: | 6.0.3 | CC: | bbuckingham, bkearney, bmbouter, daviddavis, dkliban, ggainey, ipanova, mhrivnak, mmccune, pcreech, rchan, ttereshc | |
Target Milestone: | Unspecified | |||
Target Release: | Unused | |||
Hardware: | Unspecified | |||
OS: | Unspecified | |||
Whiteboard: | ||||
Fixed In Version: | Doc Type: | Bug Fix | ||
Doc Text: | Story Points: | --- | ||
Clone Of: | ||||
: | 1145722 (view as bug list) | Environment: | ||
Last Closed: | 2015-03-30 19:36:45 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: | ||||
Bug Depends On: | 1145722 | |||
Bug Blocks: | 950746, 1115190, 1175448 |
Description
Benjamin Chardi
2014-08-27 11:50:20 UTC
Since this issue was entered in Red Hat Bugzilla, the release flag has been set to ? to ensure that it is properly evaluated for this release. What is the correct behavior in this case? Should pulp replace the previous rpm with the new one? Or should it ignore the new one and keep the old one? If there is any change to code or packaging, the NEVRA must be different. If we can assume that both RPMs are different builds of the exact same bits (spec file and all), then it shouldn't matter which one is in the repo. I'm also concerned about this turning into a broader validation feature. Should we run similar checks on upload and copy operations? What are the correct behaviors in those cases? On a large repo, such validation has the potential to noticeably impact performance. Can we limit the scope of this to say that we'll help prevent duplicate NEVRA when they come from an upstream source, but the user is expected to not make local modifications (copy or upload) that result in duplicate NEVRA? Following-up, I propose that within the world of rpm packaging, if you change the bits or spec file, you must increment at least one of the epoch, version, or release. Can we tell the user that changing the bits without bumping EVR is not supported by rpm, yum, or satellite? +1 to Michael's comment #4, if you change an RPM, increment one of the fields that indicates that the RPM has changed and do not rely entirely on the hash. Going to CLOSE:WONTFIX but if you feel this is going to have a major impact feel free to re-open with justification. The Pulp upstream bug status is at CLOSED - NOTABUG. Updating the external tracker on this bug. I don't think we need additional info anymore. |