<div dir="ltr">My naive interpretation (not having looked at pulp3 or the plugin):<div><br></div><div>#1: I believe, in your definition, the path component comes from a config option similar to relative_url in most plugins in the pulp2 world. If that is the case, then the path component should not be in the manifest, because I could theoretically sync from a remote repo into a repo with a different path component. I would imagine the manifest to be identical after the sync, and that can only happen if the path component is excluded.</div><div><br></div><div>#2: Plugin writers typically need to worry about two use cases: the ISV case (I am distributing my own files) and the redistribution case (I am caching someone else's files for efficiency). I find that very rarely do you need to combine the two, which would require the additive behavior. Complicated operations like "add files from a remote repo to the ones I distribute" or "merge two repos into one" seem to be beyond the scope of an importer configuration. So "mirror only" is enough.</div><div><br></div><div>#3: WWYD? (What Would Yum Do?) - I think you can mimic that behavior, for better or for worse. NEVRA duplicates with different checksumtype+checksum are a reality in pulp 2 already.</div><div><br></div><div><br></div><div>A few additional questions (I didn't look into the file plugin at all):</div><div>* have you considered using repomd for the "manifest"? It is ugly XML, yes, but it is a format that you already have a parser for, that is extensible, you could reuse a good bit of the syncing code from yum repos, and there are tools that know how to download repomd-aware repos, even if they are not RPMs. pulp_win settled for repomd for MSI/MSM packages for those exact reasons.</div><div>* was the subject of signatures ever brought up? It would certainly be nice for me to sign the files I am distributing, so my consumers can validate they were signed by me as an ISV. A repomd-like metadata could give you a place to store signatures. A CSV file, not so much. Detached file signatures may be an option, but would be more complicated, I think.</div></div>