Implement strict repo priority

[adriendelsalle]

Description

Implement strict repo priority
Add specific rule
Add solver flag
Add problem message/debug

Closes #458

[adriendelsalle]

Note: the block was duplicate from L3025

[adriendelsalle]

cc @wolfv

[wolfv]

we could cache the max prio here since it's the same for each s->name id. @mlschroe do you have a suggestion how to make a map? maybe we can allocate an array with the size of pool->ss.nstrings? Or is there a better way?

[wolfv]

E.g.

int* cache = solv_calloc(pool->ss.nstrings, sizeof(int));

then we can use that null-initialized buffer to cache values:

if (cache[s->name] == 0)
{
For provides ...

}
else
{
max_prio = cache[s->name] - 1;
}
...

[mlschroe]

I would do it a bit different:

1. pass the "addedmap" to the function. It contains a map of all solvables relevant for the job. This limits the amount of work we do.
2. create a copy of the map
3. change the code so that it runs over the names, not the solvables. Thus we can reuse the max prio instead of calculating it again:

map_init_clone(&todo, addedmap);
FOR_POOL_SOLVABLES(p)
  {
    if (!MAPTST(&todo, p))
      continue;
    s = pool->solvables + p;
    max_prio = s->repo->priority;
    FOR_PROVIDES(p2, pp2, s->name)
      {
        Solvable *s2 = pool->solvables + p2;
        if (s->name != s2->name)
          continue;
        if (s2->repo->priority > max_prio)
          max_prio = s2->repo->priority;
      }
    FOR_PROVIDES(p2, pp2, s->name)
      {
        Solvable *s2 = pool->solvables + p2;
        if (s->name != s2->name || !MAPTST(&todo, p2))
          continue;
        MAPCLR(&todo, p2);
        if (s2->repo < max_prio)
          solver_addrule(solv, -p2, 0, 0);
      }
  }

[mlschroe]

(The code above is completely untested)

[wolfv]

this probably never happens in the case of conda repodata, right?

[mlschroe]

It's good to do anyway as the strict repo prio code will probably be used by other distros as well.

[wolfv]

why mapclr here?

[mlschroe]

yes, that's wrong. you mustn't clear the bits in the first loop, as the second loop also does a MAPTST.

[mlschroe]

Oh wait, it only clears if the names are different. It's still wrong, though ;-)

[adriendelsalle]

Sorry I think I got it, from conda packages names of providers are always the same so I take a wrong shortcut to clear them if names differ.

In the case where s->name != s2->name we don't clear s2 but just continue to not prevent to add rules for s2->name later right?

[Conan-Kudo]

I'm not sure "strict repo priority" is the correct wording for this behavior. This describes as "weak repo priority" to me, since this explicitly makes it so higher NVRs in another repo still wins (priorities normally make it so lower NVRs win anyway, at least in DNF and Zypper).

[mlschroe]

The code doesn't check the version/release at all, so I don't understand your comment.

[Conan-Kudo]

I was mostly going off #458.

[adriendelsalle]

@mlschroe I updated that PR, if you have opportunity to take a look it would be great :)

[wolfv]

@mlschroe we've been using this in mamba for a while and seems fine! Any objection to merging it?

[SylvainCorlay]

+1 on getting this in. This appears to be fixing all the channel priority issues we've had with earlier versions.

[183amir]

I am not getting clear error messages on conflicts with mamba and strict channel priority. Is there a way to get better error messages? Please see: mamba-org/mamba#1217