Issue #6151
closed
associate-with-filter sometimes ends up with filtered-rpms in the destination
Description
Description of problem: Creating a filter to exclude a package with a higher version that has multiple versions doesn't work properly on conservative dep-solving.
Version-Release number of selected component (if applicable): 2-master
How reproducible: 100%
Steps to Reproduce:
- Turn dependency solving to conservative.
- Create and sync custom repo.
- Create cv with depsolving on and add custom repo.
- Create exclusion filter and exclude a package (walrus) with a higher version
- Publish CV
- Check rpm package list for that version
Actual results: walrus 0.71 and 5.21 are present in rpm packages list.
Expected results: walrus 0.71 is the only package present in rpm packages list.
Additional info: Without depsolving, the filtering function works as expected.
Works as expected in 2.19
Files
Updated by ggainey almost 5 years ago
Bisected to pulp_rpm commit 39e310ab:
https://github.com/pulp/pulp_rpm/commit/39e310ab3abc15d5d21b70dd910e79731f4c7a89
Updated by ggainey almost 5 years ago
John Mitsch's gist with his debugging information:
https://gist.github.com/johnpmitsch/e7aeeb6b518ef09feac7261058d0ee1e
Updated by ggainey almost 5 years ago
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
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.
Added by ggainey almost 5 years ago
Updated by ggainey almost 5 years ago
- Status changed from ASSIGNED to POST
Updated by ggainey almost 5 years ago
- Status changed from POST to MODIFIED
Applied in changeset 792554f9daaac33cc530194f1c3f26f5fb835371.
Added by ggainey almost 5 years ago
Revision abddb2b7 | View on GitHub
recursive-conservative needs to do one solve.transaction()
Doing one-per-solvable might be more robust, but leads to undesireable and/or inconsistent behavior depending on the ordering of the solvable-list. Reverting that specific piece of 39e310ab
closes #6151 https://pulp.plan.io/issues/6151
(cherry picked from commit 792554f9daaac33cc530194f1c3f26f5fb835371)
Updated by ggainey almost 5 years ago
Applied in changeset abddb2b72eb90afd04e4ba06bc2ba98c1369e340.
Updated by ipanova@redhat.com almost 5 years ago
- Status changed from MODIFIED to 5
Updated by ipanova@redhat.com almost 5 years ago
- Status changed from 5 to CLOSED - CURRENTRELEASE
.
recursive-conservative needs to do one solve.transaction()
Doing one-per-solvable might be more robust, but leads to undesireable and/or inconsistent behavior depending on the ordering of the solvable-list. Reverting that specific piece of 39e310ab
closes #6151 https://pulp.plan.io/issues/6151