RPM Support

One thing I would like to change in the Pulp 3 implementation vs. Pulp 2 is to pull depsolving completely out of the plugin and into it's own package such as "pulp_solv". We can define a nice clean API that can perform the operations needed for Pulp's use cases with a minimum of hassle, and then unit test the crap out of it. Apart from being a massive help for testing, it'll also help prevent it from making a giant confusing mess like it kind of does in Pulp 2.

Potentially, we could even make it generic enough to be used by both the RPM and Debian plugins, and maybe some other platforms libsolv supports, assuming that libsolv is the best option for those other platforms (which I don't know to be the case).

Another problem is the dependencies, such as libsolv and libmodulemd. These are typically shipped as system packages, and aren't available on all platforms.

A Libmodulemd oackage doesn't exist in the greater Debian ecosystem, nor does (as far as I can tell) a package providing Python bindings for libsolv.

Our options are:

• Use containers
• Put in the work to make those packages into pip-installable Python packages
• Tell RPM users to install the RPM packages, and Debian/Ubuntu/Mac users are SOL

Also, via discussion with Justin Sherrill, we may need to modify our implementation significantly from what Pulp 2 is capable of.

The issue, as I understand it, is that Fedora and RHEL8/CentOS 8 will have separate module repos from the standard RPM repos, and that modules can depend on RPMs in the standard repo.

In that case, it would mean that to do recursive copy, you need to support multiple input repos (the repo where the module comes from, and the repo where the standard RPM deps come from), and correspondingly multiple output repos, so that the modules are copied from one module-only repo to another, and likewise the standard RPM dependencies are copied into the target standard RPM repo.

So whereas Pulp 2 can only do this:

(recursive module copy)
[ rpms + modules ] ----> modules + rpms -----> [ rpms + modules ]

Pulp 3 may need to do this, to properly support user cases:

(in one recursive module copy operation)
[ modules ] ----> modules -----> [ modules ]
[ rpms ] ------> rpms -----> [ rpms]

(At least, one would hope we wouldn't need to implement this until Pulp 3. The timelines remain fuzzy.)

It remains an open question whether we can assume at most 2 source and 2 target repos, with matching pairs, or whether it needs to be even more general.

The amount of logic required here is another reason why we should break it off into a separate package to use as a toolkit.