'dev-python/PyQt', 'dev-python/qscintilla' and 'app-text/poppler-bindings' depend on "=x11-libs/qt-3*" but should instead inherit qt3 and depend on $(qt_min_version 3).
Please, don't file summary bugs about completely unrelated ebuilds. Honestly, I'm missing what's bad with these ebuilds deps.
Actually, I tend to prefer "=x11-libs/qt-3*" where we can get away with it, because it gets around the portage ickiness of the qt_min_version hack.
Problem shows when you run qt from SVN. As the ebuild in the KDE-SVN repository is named qt-7. the =x11-libs/qt-3* will install latest version from official portage. I know it's not a real issue with portage, but it means that we who run qt from SVN will have to either have one version of qt that isn't used, or keep an overlay with ebuilds containing these changes.
(In reply to comment #3) > Problem shows when you run qt from SVN. As the ebuild in the KDE-SVN repository > is named qt-7. the =x11-libs/qt-3* will install latest version from official > portage. Hmmm? qt is slotted for a reason. Stuff having =x11-libs/qt-3* in deps most certainly won't work at all w/ some SVN qt snapshot (and won't even work w/ qt-4, otherwise such dependency wouldn't be there). $(qt_min_version 3) won't even be satisfied by qt-4* AFAIK, let alone by qt-7. (And yeah, not really our problem if you are using SVN stuff that's not in portage.)
Created attachment 84468 [details] Overloaded qt3 eclass The SVN-repository is for the qt-3 branch. And the repository provides an overloaded qt3 eclass which says that qt-7 is ok for "qt_min_version 3*". Have a look at the attached eclass if you're interested.
All I do see is a problem with version numbering of the svn ebuild. Use e.g. 3.99 instead 7.
*** Bug 129617 has been marked as a duplicate of this bug. ***
