Changes between Version 3 and Version 4 of CompareProviders

Show
Ignore:
Author:
skvidal (IP: 98.122.161.79)
Timestamp:
05/21/10 17:38:04 (8 years ago)
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • CompareProviders

    v3 v4  
     1= Compare Providers = 
     2 
     3== the problem == 
    14When yum is depsolving and it finds that a requirement is provided for by more than one pkg it has to make a choice about which pkg to install. At one point in time it decided by choosing the 'first' one. That was too arbitrary so in casting around for a solution the yum developer used the scheme that Anaconda had used for a while which was to use the pkg with the shortest name. If the pkgs had the same 
    25length name then it took the one that sorted first, alphabetically. 
    58scoring system to judge which pkg to pick when multiple pkgs provided a dep. The method is in depsolve.py and is called _compare_providers() 
    69 
    7 Obviously if you only have one pkg (or multiple versions of the same pkg) then yum just picks the highest version of that pkg which provides the requirement. If one provider is obsoleted and another isn't, the obsoleted one is never going to be picked. 
     10== overview == 
     11This is the general overview: 
     12There are a couple things that should be fairly obvious: 
    813 
    9 Here is what _compare_providers() will do - as of roughly yum 3.2.28: 
     14- If there's only one candidate package it's picked 
     15- Obsolete packages are only picked as a last resort. 
     16 
     17Other general trends (in order of approximate precedence): 
     18 
     191)  Candidates from the same srpm as the requiring package are preferred 
     20 
     212)  Candidates with names that start the same as the requiring package are favored 
     22 
     233a) Candidates with the same (or similar) arch as the requiring package have more pull than those with a less similar arch 
     24 
     253b) Candidates with the same (or similar) arch as the system have more pulls than those with  a less similar arch 
     26 
     273c) Candidates with close relationships to the already installed system have more pull than those that would dramatically change the installed system 
     28 
     294)  In the event of a tie, candidates with very long names will lose the tie 
     30 
     31== details == 
     32Here is the detailed view  of what compare_providers() will do - as of roughly yum 3.2.28: 
    1033 
    11340. each pkg starts out with a score of 0. 
    17403. if any of the providers are obsoleted by another provider, decrease that provider by 1024.  
    1841 
    19 4. check the arch distance between the requiring pkg and each of the providers. The pkg with the smallest arch distance 
    20    gets a 5 added to their score. Do the same check but comparing the pkg arch distance to the system arch, not the requiring pkg arch 
     424. check the arch distance between the requiring pkg and each of the providers. The pkg with the smallest arch distance gets a 5 added to their score. Do the same check but comparing the pkg arch distance to the system arch, not the requiring pkg arch 
    2143 
    22445. compare the sourcerpm  on each provider to the requiring pkg's source rpm. If they share a sourcerpm add 20 to the score