Comment # 18 on bug 1175922 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.