> On Tue, Jun 9, 2009 at 3:42 PM, Markos Chandras<hwoar...@gentoo.org> wrote: > >> I wonder if someone better than I am at this can find the clue in this > >> big, ugly qt blockage? Seems like sometimes possibly it's complaining > >> about qt-4.5 vs qt-4.4 while other times it's complaining about 4.5.1 > >> vs 4.5.1. > >> > >> Sometimes it says > >> [blocks b ] > > >> > >> while other times it says > >> [blocks b ] < > > > > These blockages come from qt4-build eclass. They prevent you from mixing > > qt version ( having some packages on 4.5.1 and some others on 4.4.2 ). > > > > use emerge -uDN world and you should be fine > > > > If 4.5.1 is still keyworded for your architecture, make sure to keyword > > all qt modules before proceeding with emerge -uDN world > > > > Thanks > > -- > > Markos Chandras (hwoarang) > > Gentoo Linux Developer [KDE/Qt/Sunrise/Sound] > > Web: http://hwoarang.silverarrow.org > > Indeed, now there's the answer. The previous printout was from an > emerge -DuN @system. I got both red and blue blockage responses which > emerge won't fix by itself. In this case switching to emerge -DuN > @world removes the problem and shows everything as blue. > > Granted - it's 28 packages instead of 12, but that's OK. > > Now, I'm currently running the emerge -DuN world to get the job done, > but when it finishes I'd like to understand what parts of @system are > requiring qt at all. I seem to think that somehow I've added flags to > @system level packages that maybe I don't need? > > Thanks! > > - Mark
Well, you can stop the emerge -uDN world now and use emerge -uDNavt @system. -t parameter will printout the full dependency graph and you can see what system package is pulling the qt libraries ;) -- Markos Chandras (hwoarang) Gentoo Linux Developer [KDE/Qt/Sunrise/Sound] Web: http://hwoarang.silverarrow.org
signature.asc
Description: This is a digitally signed message part.
