On 11/08/2014 02:24 PM, Patrick Lauer wrote: > On 11/08/2014 03:08 AM, hasufell wrote: >> On 11/07/2014 07:54 PM, Matthias Maier wrote: >>>> Well, you're not comparing like with like. Paludis with "everything >>>> turned off" does more than Portage with "everything turned on". If all >>>> you're looking for is the wrong answer as fast as possible, there are >>>> easier ways of getting it... >>> >>> The last time I compared the resolver speed of portage and paludis both >>> needed almost the same time. >>> >>> Do you have a speed comparison with a similar feature set of both? (Or, >>> alternatively, the speedup one gains by tuning paludis to be as fast as >>> possible). >>> >> >> I think you didn't get the idea: it doesn't make much sense to compare >> the speed if the correctness differs. >> >> Also, I don't understand these discussions. The time dependency >> resolving takes is marginal compared to the whole update process, no >> matter what PM you use. >> > *ahem* > > On my old notebook, which luckily suicided thanks to Lenovo's built in > obsolete device detection ... > > emerge -auNDv world took up to 35 minutes > > So, if something like RUBY_TARGETS or a random useflag changes, it takes > me literally DAYS to figure out a valid solution where portage can > figure out an upgrade path. > > No, it's not marginal. >
So we are back to the initial discussion: fix the input instead of making the resolver even worse. You can't have both bad input and a fast _correct_ resolver. So you choose between "good enough results which may not be what you want" and "pretty good results with lots of things to figure out yourself, because of the input and because the resolver does not make random assumptions about what you want". Both solutions s**k, tbh. I'd just like people to look at the whole picture and don't keep PM discussions narrow-minded by all this NIH crap.
