On 26/01/2014 17:24, eroen wrote: > On Sun, 26 Jan 2014 16:35:43 +0200, Nikos Chantziaras > <[email protected]> wrote: >> Anyone else noticed this yet? Some portage update seems to have made >> "emerge -uDN @world" perform about 10 times slower than before. It >> used to take seconds, now it takes about 4 minutes only to tell me >> that there's nothing to update. And it does that every time, even >> directly in succession and with the caches warm. >> >> Is it just me? > > You don't say when your baseline was, but the complexity of resolving > the package tree has increased quite a bit over the last year due to > new features like automatic rebuilds of consumers after library updates. > > Another somewhat common cause of sudden slowdowns is how portage > resolves conflicts (like packageA requiring an old version of libraryB), > which is rather time-consuming. You can try adding --backtrack=0 to the > emerge command to make it stop and print an error message when > encountering a conflict rather than look for a solution. Then you can > 'help' out by manually resolving any conflicts by adding package > versions to /etc/portage/package.mask . Preferably try this *after* > running an update, so your system is up-to-date against your local > version of the gentoo tree, otherwise "normal" simple-to-resolve > conflicts might cause confusion. ;-) >
I've been noticing these slowdowns for a few months now too. I'm somewhat conflicted in my head about them, as unresolved blockers is now something that happens very rarely. How often did we do this in the past: emerge -avuND world stare at output trying to figure out wtf? emerge -C <some problem package> emerge -avuND world emerge problem package back if world update didn't already do it That used to happen A LOT, and it took much longer than 4 minutes. Nowadays it happens seldom but the resolution does take 4 minutes. So I dunno, it's annoying to have to wait, but it also prevents a lot of wasted time by doing what software can do so well - detecting dependency issues. -- Alan McKinnon [email protected]
