| 1 |
On 11/08/2014 10:48 PM, hasufell wrote: |
| 2 |
> On 11/08/2014 02:24 PM, Patrick Lauer wrote: |
| 3 |
>> On 11/08/2014 03:08 AM, hasufell wrote: |
| 4 |
>>> On 11/07/2014 07:54 PM, Matthias Maier wrote: |
| 5 |
>>>>> Well, you're not comparing like with like. Paludis with "everything |
| 6 |
>>>>> turned off" does more than Portage with "everything turned on". If all |
| 7 |
>>>>> you're looking for is the wrong answer as fast as possible, there are |
| 8 |
>>>>> easier ways of getting it... |
| 9 |
>>>> |
| 10 |
>>>> The last time I compared the resolver speed of portage and paludis both |
| 11 |
>>>> needed almost the same time. |
| 12 |
>>>> |
| 13 |
>>>> Do you have a speed comparison with a similar feature set of both? (Or, |
| 14 |
>>>> alternatively, the speedup one gains by tuning paludis to be as fast as |
| 15 |
>>>> possible). |
| 16 |
>>>> |
| 17 |
>>> |
| 18 |
>>> I think you didn't get the idea: it doesn't make much sense to compare |
| 19 |
>>> the speed if the correctness differs. |
| 20 |
>>> |
| 21 |
>>> Also, I don't understand these discussions. The time dependency |
| 22 |
>>> resolving takes is marginal compared to the whole update process, no |
| 23 |
>>> matter what PM you use. |
| 24 |
>>> |
| 25 |
>> *ahem* |
| 26 |
>> |
| 27 |
>> On my old notebook, which luckily suicided thanks to Lenovo's built in |
| 28 |
>> obsolete device detection ... |
| 29 |
>> |
| 30 |
>> emerge -auNDv world took up to 35 minutes |
| 31 |
>> |
| 32 |
>> So, if something like RUBY_TARGETS or a random useflag changes, it takes |
| 33 |
>> me literally DAYS to figure out a valid solution where portage can |
| 34 |
>> figure out an upgrade path. |
| 35 |
>> |
| 36 |
>> No, it's not marginal. |
| 37 |
>> |
| 38 |
> |
| 39 |
> So we are back to the initial discussion: fix the input instead of |
| 40 |
> making the resolver even worse. You can't have both bad input and a fast |
| 41 |
> _correct_ resolver. |
| 42 |
|
| 43 |
... ... .... eeeeeeeeh? |
| 44 |
|
| 45 |
If I'm telling portage to not enable mysql support, and some kde bits |
| 46 |
through a transitive dependency need the mysql useflag enabled on |
| 47 |
$whateverlib, then portage can't find a valid solution because of my |
| 48 |
local decisions. |
| 49 |
|
| 50 |
There's nothing gentoo can do in terms of policy or ebuild changes to |
| 51 |
avoid that apart from removing all useflags and making me install debian |
| 52 |
instead (just to find a variation of that problem with apt) |
| 53 |
|
| 54 |
> |
| 55 |
> So you choose between "good enough results which may not be what you |
| 56 |
> want" and "pretty good results with lots of things to figure out |
| 57 |
> yourself, because of the input and because the resolver does not make |
| 58 |
> random assumptions about what you want". |
| 59 |
|
| 60 |
We can choose for "code that works reasonably fast" - portage hasn't |
| 61 |
gotten any noticeable work on performance in a while, and people have |
| 62 |
just piled on more and more features and complexity. There's no reason |
| 63 |
that it takes a minute to start up, so let's focus on fixing that |
| 64 |
instead of trying to write a dependency resolution algorithm that |
| 65 |
assumes the Riemann Hypothesis is correct. |
| 66 |
> |
| 67 |
> Both solutions s**k, tbh. |
| 68 |
> |
| 69 |
> I'd just like people to look at the whole picture and don't keep PM |
| 70 |
> discussions narrow-minded by all this NIH crap. |
| 71 |
> |
| 72 |
It's not about NIH, it's about slow code being slow. |
Archives