[Pulp-dev] File plugin planning: questions

[Mihai Ibanescu]

My naive interpretation (not having looked at pulp3 or the plugin):

#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.

#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.

#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.


A few additional questions (I didn't look into the file plugin at all):
* 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.
* 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20180130/7c52dd3b/attachment.htm>