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* )" Thanks, Niek. Reproducible: Always Steps to Reproduce: $ emerge -up opera -snip- [ebuild UD] x11-libs/qt-3.3.0-r1 [5] [ebuild U ] net-www/opera-7.23-r1 [7.23] $ emerge -s ^qt$ -snip- * x11-libs/qt Latest version available: 5 Latest version installed: 5 Size of downloaded files: 0 kB Homepage: http://www.trolltech.com/ 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.
