1 |
Michał Górny <mgorny@g.o> wrote: |
2 |
>> |
3 |
>> d. In || ( ... ) clauses the left-most packages should be preserved. |
4 |
|
5 |
s/preserved/preferred/ |
6 |
|
7 |
> you've missed the most important point: we want to prefer |
8 |
> the newest version, whenever possible |
9 |
> ;-). |
10 |
|
11 |
Yes, you are right: I had thought only about packages, not about versions. |
12 |
Of course, a version upgrade within the same slot should have a |
13 |
negative penalty. I am already not sure how upgrades with slot |
14 |
changes should be treated. And then there are subslots... |
15 |
The list is probably still not exhaustive and - as already mentioned - |
16 |
the penalties are certainly a topic of discussion (and even more of |
17 |
trial and error: which works best in practice). |
18 |
|
19 |
Anyway, I think that it would be a huge improvement over the current |
20 |
(portage's) solver if one could formulate such a list explicitly in |
21 |
some specified format, and then one abstract algorithm takes care to |
22 |
find the best solution according to the specified penalties: |
23 |
If I understand it correctly, all these rules are currently hard-coded |
24 |
into the algorithm by using various hacks in backtracking steps, |
25 |
finding of a solution is convoluted with determining the order, etc. |
26 |
One would obtain a solver which not only is "provably" correct, |
27 |
but also much easier to maintain and to tweak (e.g. if one realizes |
28 |
that certain penalties were not cleverly chosen). |
29 |
|
30 |
This would also provide the possibility for much richer user configuration. |
31 |
An example which immediately come to mind is "weak-masking" of packages |
32 |
or versions ("use it or upgrade only if no alternative is available"). |
33 |
Theoretically, one could then even endow the entries of package.mask |
34 |
with a penalty number. |