On 11/08/2014 10:48 PM, hasufell wrote: > 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.
... ... .... eeeeeeeeh? If I'm telling portage to not enable mysql support, and some kde bits through a transitive dependency need the mysql useflag enabled on $whateverlib, then portage can't find a valid solution because of my local decisions. There's nothing gentoo can do in terms of policy or ebuild changes to avoid that apart from removing all useflags and making me install debian instead (just to find a variation of that problem with apt) > > 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". We can choose for "code that works reasonably fast" - portage hasn't gotten any noticeable work on performance in a while, and people have just piled on more and more features and complexity. There's no reason that it takes a minute to start up, so let's focus on fixing that instead of trying to write a dependency resolution algorithm that assumes the Riemann Hypothesis is correct. > > 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. > It's not about NIH, it's about slow code being slow.
