On Friday 31 Jan 2014 19:03:05 Andrew Savchenko wrote: > On Sun, 26 Jan 2014 20:30:19 +0200 Alan McKinnon wrote: > > It comes from watching what happens at the end of running emerge, don't > > read any more into it than that. Especially not optimism, I think you > > might be projecting your own frustrations. > > > > A couple of years ago I used to have to manually resolve blockers about > > one world update in two. It started becoming a huge PITA especially as > > the deps are usually easy to solve - if I can look at the screen for a > > few seconds and figure it out, then software can do the same in > > milliseconds. Recent portages now do this properly when viewed from a > > results-only perspective. > > > > On my machines, that is what I see happening. That is the ONLY set of > > FACTS I have to work on; you may have more. > > > > I'm willing to give up 4 minutes while emerge runs so I don't have to > > spend many more minutes right afterwards doing manually the very shit > > that software is very good at. Whether portage is a complete pile of > > dogshit software or not is beside the point. Even if it is, my 4 minutes > > still buys me lots <shrug> > > 4 minutes are expendable but... on Atom N270 (my laptop) emerge > -DNuav world takes 40 (yes, forty) minutes to build dependency tree > with sqlite cache enabled and 60 minutes without sqlite. System was > pretty old (not updated aside from GLSA updates for a year). And this > 40 minutes repeated many times since USE flag clashes and dependency > resolution failures. So I spent may day, damn whole day(!) for the > sake to just start compiling (distcc is my friend here).
Out of interest what fs are you running portage on? I changed an old box from reiserfs to ext4 and couldn't believe the speed up I got. -- Regards, Mick
signature.asc
Description: This is a digitally signed message part.