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

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply via email to