https://bugzilla.suse.com/show_bug.cgi?id=1175922
https://bugzilla.suse.com/show_bug.cgi?id=1175922#c18
Michael Schröder changed:
What |Removed |Added
----------------------------------------------------------------------------
Flags|needinfo?(mls@suse.com) |
--- Comment #18 from Michael Schröder ---
You can actually influence this by putting the "lock" jobs after the normal
jobs. But all this is somewhat heuristic.
The "break dependency" option is not a libsolv feature, but done by libzypp.
Libzypp (mis-)uses findproblemrule to calculate which package to break. In your
case you'll get:
ANALYZE UNSOLVABLE ----------------------
Rule #4:
!client-0-0.x86_64 [4] (w1) Install.level1
server-0-0.x86_64 [3] (w2) Conflict.level1
next rules: 0 0
Rule #3:
!test-0-0.x86_64 [5] (w1) Install.level1
client-0-0.x86_64 [4] (w2) Install.level1
next rules: 0 0
JOB Rule #7:
!server-0-0.x86_64 [3] (w1) Conflict.level1
next rules: 0 0
JOB Rule #5:
test-0-0.x86_64 [5] (w1) Install.level1
next rules: 0 0
So there are two candidates for breaking package dependencies: client and test.
findproblemrule() basically used the one that led to the conflict.
So if the order is:
- conflict server
- install test
- propagate server dependencies
it will offer to break server.
If the order is:
- install test
- conflict server
- propagate test dependencies
it will offer to break test.
Job rules are fulfilled in order.
Maybe it would be better to offer both possibilities and let the user choose
the one that makes sense, but this can lead to lots of choices...
We can also try to be more clever in findproblemrule(), but this is somewhat
non-trivial and may lead to other complaints.
--
You are receiving this mail because:
You are on the CC list for the bug.