Pull Request Check List

Resolves: #6054

I think that the fix made at #5770 was not good. (I did review it at the time without seeing problems, so no blame!)

As I now understand it, the problem that it was trying to solve was:

• we register a direct-origin assignment for foo
• we then register a regular assignment for foo[extras]
• we'd like for the result to be that all foo-related assignments find the direct-origin package
• but that's not what happens

#5770 fixed this by finding the foo assignment at the second bullet, and then the intersection of a direct-origin and not-direct-origin term always favours the direct-origin.

I think this is probably unreliable: eg in the first bullet we might have registered a direct-origin assignment for foo[other-extras]. Or bullets 1 and 2 might happen the other way round.

Apart from that, #6054 exposed a problem where we registered regular assignments for foo and foo[extras], but with incompatible version ranges. Before #5770 that was fine and is unwound later in the search, but after #5770 we try to update the foo assignment and go wrong.

This MR undoes the fix of #5770 and tries another. I have arranged that:

• we always try to resolve direct-origin dependencies first
• the provider remembers direct-origin dependencies and returns them again if asked for the same package but with different features

That fixes the original #5311 because now the direct-origin version of the foo package is the only one that we ever see; and, per the new testcase, unbreaks #6054