I had the same problems. Putting qt-phonon into /etc/portage/package.mask didn't solve it. strigi wanted qt-4.3.x.

I don't know, if all the procedure is necessary. At least it seemed to me the only working chance:

1. Deinstall all the qt-stuff (qt-core, qt-gui, qt-opengl...)
2. Put app-misc/strigi-0.6.4 into /etc/portage/profiles/package.provided
3. If enabled in /etc/make.conf, disable phonon in the USE-flags (with phonon enabled, it's not possible to emerge the qt-stuff)
4. Deinstall the kde4-stuff, which is complaining about in emerge -puDN world, deinstall kdelibs-4.2.x
5. emerge kdelibs. That will install the qt-stuff and all the other depencies - hopefully without qt-phonon
6. At the point when kdelibs itself has to be merged, kdelibs will fail to compile while configuring. At this point you have to remove the strigi-entry in /etc/portage/profiles/package.provided.
7. emerge kdelibs will install strigi (without qt-4.3.x) and finally kdelibs.

Last edited by musv on Thu Feb 19, 2009 9:19 am; edited 1 time in total

It may be possible to solve this problem by using package.mask to
prevent one of those packages from being selected. However, it is also
possible that conflicting dependencies exist such that they are
impossible to satisfy simultaneously. If such a conflict exists in the
dependencies of two different packages, then those packages can not be
installed simultaneously.

For more information, see MASKED PACKAGES section in the emerge man page
or refer to the Gentoo Handbook.

Hi all,
short summary question for the slower people like me.
Looks like I have to upgrade:

Code:

These are the packages that would be merged, in order:

Calculating dependencies... done!

!!! All ebuilds that could satisfy "~x11-libs/qt-dbus-4.5.0" have been masked.
!!! One of the following masked packages is required to complete your request:
- x11-libs/qt-dbus-4.5.0 (masked by: ~amd64 keyword)

For more information, see the MASKED PACKAGES section in the emerge
man page or refer to the Gentoo Handbook.
(dependency required by "x11-libs/qt-4.5.0" [ebuild])
(dependency required by "world" [argument])

Unmerging qt-4.4.2 should not be a problem here but I`d have to unmerge stellarium as well:

I don't know what is pulling the ~amd64 version (4.5.0) for you, but you should be able to use the stable version (4.4.2). If your portage is up to date, then the upgrade should be smooth. And yes, stellarium can use the split qt ebuilds (both stable 4.4.2 and testing 4.5.0 versions)._________________"Those who deny freedom to others deserve it not for themselves." - Abraham Lincoln
Free Culture | Defective by Design | EFF

OK, I'm lost here. I followed the nice abstract discussion on the first couple pages, but for some reason my particular situation does not seem to make any sense. That said, I've been up for almost 30 hours trying to get this %@#@$@ box working.

For some reason, everyone on this thread is talking about an upgrade to 4.4, and the way I read this my system wants to downgrade to 4.3? Say it ain't so.

Background: For some reason in the distant past, I upgraded to a beta glibc and xorg. I've been stuck with it since, and have been considering a re-install to get around the mistake. I just checked, and glibc's stable version has surpassed my beta one, and xorg seems to be reasonable too. So I decided to paint new lines instead of rebuilding the highway, so to speak.

I think if I took a nap, I might be able to make sense of the above block of junk. However, I would like to leave my emerge running for however long it takes, if it will run that long.

So, the questions I need to have answered, if somebody will be so kind:
Is my system trying to upgrade or downgrade?
If it's trying to downgrade, is that safe for this particular setup?

Thanks.

Edit: Oh, heck. I thought of another question.
Will portage handle all that without intervention, or will it blow up and leave me with a tatered system in the morning?

So, let me see if I understand this correctly. Qt-4.5 is currently around the corner and those of us who are currently dealing with the 4.4 situation (which I'm admittedly unclear as to how to resolve at the moment), will likely be having to deal with this very same type of situation yet again in the upcoming few weeks or months?

No. The upgrade is smooth now. Just make sure you have synced and your portage (the program itself) is up to date. This topic is basically obsolete now. Monolithic Qt 4.3 was hardmasked and is no longer in the tree. Portage has a much more intelligent dependency resolver and block handler now. So in almost all cases upgrading or installing Qt4 should be no problem at all. There may be a few minor issues you may have to deal with, but of course we're happy to help._________________"Those who deny freedom to others deserve it not for themselves." - Abraham Lincoln
Free Culture | Defective by Design | EFF

PyQt4-4.3.3 is no longer in portage, so a world update should offer you an upgrade to 4.4.4. Are you sure you haven't masked any upgrades?

If you still have problems, you could try unmerging the problematic packages (try `equery depends qt:4` to find them), unmerging qt-4.3*, and then reinstalling the packages you want/need. That should pull in the current qt packages._________________"Those who deny freedom to others deserve it not for themselves." - Abraham Lincoln
Free Culture | Defective by Design | EFF

Thanks for the advice, I'll try it when I have time to risk this upgrade.

There is no risk. You just have some very outdated packages. It's safe enough to unmerge poppler-bindings, PyQt4 and qscintilla, as well as qt-4.3*. You should also unmerge app-text/poppler, and migrate to dev-libs/poppler, and then install poppler-qt4 instead of poppler-bindings. When you reinstall PyQt4, you should get the new 4.4.4 version, which will also pull in the Qt packages you need. An emerge -avuD world finally should bring you all up to date then._________________"Those who deny freedom to others deserve it not for themselves." - Abraham Lincoln
Free Culture | Defective by Design | EFF

you should not try to upgrade via emerge -pv world but use emerge -avuD world or -avuND world. This will update all deep dependencies too.
And, especially have portage up-to-date too, before you attempt to update!_________________Knowledge is scary....