On 29 Jun, Dale wrote: > Helmut Jarausch wrote: >> Hi, >> >> I'm using portage-2.2_rc33. And it has become smarter with every new >> release. Still, I don't understand why it's sometimes smarter than other >> times. >> >> In most cases now, it's able to handle cases where installed old >> packages which depend on, say, libXX-version-1, block emerging >> libXX-version-2 by unmerging the old version itself. >> >> But sometimes, like today when upgrading from various qt-...-4.5.1 >> to qt-...-4.5.2 packages it produces tons of blockings which it >> cannot resolve itself. >> >> How can I help portage to resolve this blockings itself in a smart way? >> (trying to do >> emerge --keep-going -j2 -1 --ask --update --newuse --deep @system @world >> automatically. >> ) >> >> Many thanks for a hint, >> Helmut. >> >> > > Another thought to. The option --with-bdeps y may help. It may not but > it could be worth a try. I have ran into problems where that helped and > have read where a few others have ran into similar problems and that > fixed it. It just tells emerge to dig a little deeper from my > understanding. > > Can't think of anything else at the moment. >
Thanks Dale, --with-bdeps y seems to help. By the way, the '-j <n>' option of emerge has nothing to do with the MAKEOPTS option. The -j option of emerge require parallel emerging of several packages at a time while the -j option in MAKEOPTS requires parallel make of a single package. In some phases (like configure, bzip of the man pages, etc) emerge cannot use multiple cores for a single package. Therefore the -j option of emerge tries to emerge several packages at a time unless dependencies forbid that. It's quite clever in that respect. Helmut. -- Helmut Jarausch Lehrstuhl fuer Numerische Mathematik RWTH - Aachen University D 52056 Aachen, Germany
