RPM Support

Bisected to pulp_rpm commit 39e310ab:

https://github.com/pulp/pulp_rpm/commit/39e310ab3abc15d5d21b70dd910e79731f4c7a89

John Mitsch's gist with his debugging information:

https://gist.github.com/johnpmitsch/e7aeeb6b518ef09feac7261058d0ee1e

This regression is the result of an attempt to make depsolving more robust in the face of multiple dependency-errors.

Prior to the commit mentioned in #1, find_dependent_solvables_conservative() would build a list of all the solvables resulting from the filtering provided to /associate, and then run solver.transaction() all at once. One of the changes made in that commit, is to instead solve per-unit, dealing with any fallout on a per-unit basis - see

https://github.com/pulp/pulp_rpm/blob/2-master/plugins/pulp_rpm/plugins/importers/yum/pulp_solv.py#L985-L986

and note that we are inside the "while solvables_to_copy' loop.

This works, until we get into the situation described here, where we have a unit (chimpanzee) that has a dependency (walrus) that we haven't seen yet, and which is in the source repo. Depsolving in isolation results in chimpanzee pulling in the most up-to-date version(s) of its dependencies that the Solver can find, resulting in walrus-5.21 being pulled in from the repo.

When depsolving happened for the entire list at once, it would find the walrus-0.71 from the list, in preference to the 5.21 from the repo, and all was well.

Working on figuring out what the best way to fix this is.

Applied in changeset abddb2b72eb90afd04e4ba06bc2ba98c1369e340.