The opera-7.23-r1 ebuild depends on QT version 3.x. I'm using the KDE-CVS ebuilds (http://www.gentoo.org/proj/en/desktop/kde/kde-cvs.xml) instead of the stable ones, so I have installed QT version 5. Please change the following line in the Opera ebuild:
From: !static? ( =x11-libs/qt-3* )"
To: !static? ( >=x11-libs/qt-3* )"
Steps to Reproduce:
$ emerge -up opera
[ebuild UD] x11-libs/qt-3.3.0-r1 
[ebuild U ] net-www/opera-7.23-r1 [7.23]
$ emerge -s ^qt$
Latest version available: 5
Latest version installed: 5
Size of downloaded files: 0 kB
Description: QT from the qt-copy module of KDE cvs
License: QPL-1.0 | GPL-2
sorry, since kde-cvs ebuild is not offically supported and opera most likely won't work with qt 4, i can't change that
I do _NOT_ agree with this.
It will take at least 6 months from now before Qt 4 will go beta. It's really stupid to force users _NOW_ to install the stable Qt ebuild when they've also installed Qt 3 from CVS.
At the time Qt 4 is out we can simply modify the ebuild to fetch another tarball if availible (knowing Espend Sand, this will be the case) or just block Qt 4 users.
The package net-p2p/azureus-bin (and I guess more packages) has exactly the same problem. It depends on =x11-libs/qt-3* and =kde-base/kdelibs-3*. This is even more stupid: the systraydaemon part in Azureus is compiled from source, and because Qt 4 will be 99% source compatible with Qt 3 forcing users to install Qt/KDE 3 is plain wrong.
You should have this problem with every ebuild that uses the kde elcass since "need-qt 3" adds the following dep ~x11-libs/qt-3. We don't support the cvs version of qt so we won't change the dep, you can change the naming scheme of your ebuild to 3.YYYY.MM.DD.