-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/26/2014 06:42 PM, Alan McKinnon wrote: > On 26/01/2014 17:24, eroen wrote: >> On Sun, 26 Jan 2014 16:35:43 +0200, Nikos Chantziaras >> <rea...@gmail.com> 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. > > >
Dependency resolution is broken and incomplete. Portage is unable to print useful autounmask and similar messages to solve conflicts manually, is unable to solve circular deps at all and bails out on simple things like only updating vim when gvim is installed as well. Then we have dirty workarounds like PDEPEND which shouldn't be there in the first place... It's a miracle that it works at all, especially when people keep breaking the cache and rely on undefined behavior. Also... we still have binary files in the tree. Each EAPI adds more complexity to the dependency calculation. We have no performance regression tests. We don't have many people who want to look into portage code (can't blame them and since ferringb is gone we don't have any1 who works on the QA-side of the code). Afais, it will get a lot worse. So, not sure where your optimism comes from. But... some devs are interested in starting from scratch or picking up pkgcore (which would be the most sane thing to do IMO). -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJS5U40AAoJEFpvPKfnPDWziK0IAKwuPe4DOBvamSkhtYbipZOv CdCmt4qjlYn/NjLMkyb8I5AO1m3rziHKuFnfMAksFodTZx9HJ8rbXh1H75bGNt+i k1cJ4Z6eg9R6hHqsBXAdwBfl4eDouINYMs2Q2R85XFD2QdZKUE/8AcUU5s2YHkxR NraYC/1n2LxUaXwA8D66KNHKSR31Gb5ISd+Slt+kvAGpXjRDJCDRAWD/QChPkVUL 06RA6qjIhmAooWo3x5lcBjpGUsVkiPk15sF3E0t1qyjp78eiOq8cZBMRYxnhUVN+ AtQlESyzVmYjaCI557fsPr6sZasD69U9luZM6UUToeDSoK7O81s99MilhqUGpKA= =vPSH -----END PGP SIGNATURE-----
