| 1 |
On 11/08/2014 03:52 PM, hasufell wrote: |
| 2 |
> On 11/08/2014 11:39 PM, Zac Medico wrote: |
| 3 |
>> On 11/08/2014 02:05 PM, hasufell wrote: |
| 4 |
>>> I have a feeling that this is an assumption as well. PMS just says this |
| 5 |
>>> is an 'any-of' group. There is not a single word about the processing |
| 6 |
>>> order of these specs or which one to prefer, in which case some is |
| 7 |
>>> better than the other and so on. |
| 8 |
>> |
| 9 |
>> I think the two obvious algorithms are: |
| 10 |
>> |
| 11 |
>> A) If the user's resolver parameters request maximum upgrades, then the |
| 12 |
>> resolver should choose the choice that results the most upgrades. |
| 13 |
>> |
| 14 |
> |
| 15 |
> Neither the first nor the second dependency spec group in this example |
| 16 |
> leads to an upgrade. |
| 17 |
|
| 18 |
If you consider "not downgrading" equivalent to an upgrade, the then the |
| 19 |
second dependency spec wins (the one on the "right"). |
| 20 |
|
| 21 |
|
| 22 |
>> B) If the user's resolver parameters request minimum change, then the |
| 23 |
>> resolver should choose the choice which results in keeping the most |
| 24 |
>> installed packages in place. |
| 25 |
>> |
| 26 |
> |
| 27 |
> I don't know of any such switch in portage or paludis (I may be wrong, |
| 28 |
> please point me to it unless you mean --nodeps). |
| 29 |
|
| 30 |
For portage, absence of the emerge --update parameter will trigger a |
| 31 |
"minimum change" behavior for packages that are not matched by argument |
| 32 |
atoms. |
| 33 |
|
| 34 |
> Whether I get minimum |
| 35 |
> change is a side effect of other choices and hardly predictable, afais, no? |
| 36 |
|
| 37 |
Consider it a "best effort" algorithm. Some other constraints may |
| 38 |
override the minimum change request. |
| 39 |
-- |
| 40 |
Thanks, |
| 41 |
Zac |
Archives