[EPIC] Revisit architecture around relative_path to fully/correctly handle atypical repository-layouts
pulp_rpm assumes that RPM Repositories follow certain rules, including:
- One NEVRA can appear only once in a repository
- A given artifact-checksum can appear at most once in a repository
- It is always desireable to have repositories published using the Packages/n/nevra.rpm format
In actual real-worlkd practice, these rules are...more like a set of guidelines, really. As a result, there are real-world repositories that pulp_rpm cannot sync.
Issues have been reported 1 2 against a number of repositories 3 4 5 6 7, a lot of investigation has gone into identifying potential architectural changes to address the problem 8, and several workarounds 9 10 have been implemented to allow users to have usable repositories even in the face of the problem (along with the low-level findings while researching possible workarounds 11
The workarounds are just that - special-case code that works around the architectural issue(s) in order to get users going again, while minimizing destabilizing impact (esp to pulpcore). We need to step back and reconsider the assumptions above, and provide architectural support for handling the exception-cases listed, making them first-class approaches rather than exception-code.
Please register to edit this issue