| 1 |
On 11/08/2014 03:08 AM, hasufell wrote: |
| 2 |
> On 11/07/2014 07:54 PM, Matthias Maier wrote: |
| 3 |
>>> Well, you're not comparing like with like. Paludis with "everything |
| 4 |
>>> turned off" does more than Portage with "everything turned on". If all |
| 5 |
>>> you're looking for is the wrong answer as fast as possible, there are |
| 6 |
>>> easier ways of getting it... |
| 7 |
>> |
| 8 |
>> The last time I compared the resolver speed of portage and paludis both |
| 9 |
>> needed almost the same time. |
| 10 |
>> |
| 11 |
>> Do you have a speed comparison with a similar feature set of both? (Or, |
| 12 |
>> alternatively, the speedup one gains by tuning paludis to be as fast as |
| 13 |
>> possible). |
| 14 |
>> |
| 15 |
> |
| 16 |
> I think you didn't get the idea: it doesn't make much sense to compare |
| 17 |
> the speed if the correctness differs. |
| 18 |
> |
| 19 |
> Also, I don't understand these discussions. The time dependency |
| 20 |
> resolving takes is marginal compared to the whole update process, no |
| 21 |
> matter what PM you use. |
| 22 |
> |
| 23 |
*ahem* |
| 24 |
|
| 25 |
On my old notebook, which luckily suicided thanks to Lenovo's built in |
| 26 |
obsolete device detection ... |
| 27 |
|
| 28 |
emerge -auNDv world took up to 35 minutes |
| 29 |
|
| 30 |
So, if something like RUBY_TARGETS or a random useflag changes, it takes |
| 31 |
me literally DAYS to figure out a valid solution where portage can |
| 32 |
figure out an upgrade path. |
| 33 |
|
| 34 |
No, it's not marginal. |
Archives