Helmut Jarausch wrote: > 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. > >
Dang portage. It just gets better all the time. ;-) Glad that helped. Dale :-) :-)
