This is where we can pose thoughts and related issues to having both qt3 and qt4 installed at the same time. Right now, it should *just work*. What we need to do is update portage deps to handle this scenario. Things to fix: 1) ebuilds with deps like ">=x11-libs/qt-3.3.2" 2) ebuilds that use the need-qt function 3) ebuilds that call qmake somewhere in the src_compile() function #3 should be easy. Change all occurrences of qmake to $QTDIR/qmake, since QTDIR is not used in Qt4. 2) Can we deprecate this, and just rely on a straight dependency in the ebuild? 1) Change ebuilds to have deps like: "=x11-libs/qt-3.3*" ? There are problem some fringe cases, but it will probably help to get started sooner than later. Thoughts? Reproducible: Always Steps to Reproduce:
I assume that portage can handle this: DEPEND="=x11-libs/qt-3* >=x11-libs/qt-3.3.1". Maybe just updating the ebuilds in portage to use this type of syntax would work?
>I assume that portage can handle this: >DEPEND="=x11-libs/qt-3* >=x11-libs/qt-3.3.1". Iirc it doesn't. This would need general support for ranges. >1) ebuilds with deps like ">=x11-libs/qt-3.3.2" Can be changed to <qt-4. The portage tree is not a snapshot. Users have to adapt. ;) >2) ebuilds that use the need-qt function >3) ebuilds that call qmake somewhere in the src_compile() function There are a number of things needed to improve regarding kde* eclasses 1. Switching from need-foo() to NEED_FOO="bar" to comply with GLEP 33 2. Dealing of qmake/.pro issues inside an eclass, instead reinventing the whell with every qt related ebuild. 3. Proper support of application which can be build against Qt or KDE inside eclass. 4. support scons build scripts via eclass 5. _Not_ building against the latest available kde version, but against kde-config --prefix or user defined one (e.g. reusing KDEDIR for this purpose), similiar approach needed for Qt as well 6. may have missed something >2) Can we deprecate this, and just rely on a straight dependency in the ebuild? There are two ways to deprecate it: Turn it into a variable (to be set before inherit) or explicitly setting the needed dependency/ies in every ebuild.
Ooh, my brain was going crazy when I suddenly thought of a way that we might be able to make all of this a LOT easier! Why not name the package "qt4" ? Okay, it's a hack, but it might make things a lot easier...
Barring that, what about this: Any ebuild that currently has something like this: >=x11-libs/qt-3 Change to =x11-libs/qt-3 Easy. For more interesting cases, create a qt3.eclass which creates: QT3VERSIONS="|| ( qt-3.0.1-r1 qt-3.0.1-r2 qt-3.0.1-r3 ... qt-3.3.4-r5 )" and then in an ebuild: DEPEND="$QT3VERSIONS" And we can create some eclass function to dynamically create QT3VERSIONS based on what you tell it: DEPEND="$(qt3_version_min 3.1)" or something like that...
I've committed qt.eclass which is an initial handler for ebuilds which need Qt. The stuff in the ebuild itself is a bit of a hack (could be much prettier), but in a nutshell, an ebuild should be able to: inherit qt DEPEND="$(qt3_min_version 3.0)" and it should just work (it does so by expanding out all of the known version of Qt which would work: IE: DEPEND="||(x11-libs/qt-3.3.4-r5 x11-libs/qt-3.3.4-r4 ... x11-libs/qt-3.3.0)" As a special case, if a user specifies 3, 3.0, or 3.0.0, then it expands to: DEPEND="|| ( x11-libs/qt-3* )" Thoughts?
I also put in a qt_pkg_setup function which handles the setting of QTDIR, so I believe that other than a possible 'addwrite' the qt eclass can replace the use of need-qt and set-qtdir in kde-functions.eclass.
I've gone through portage and updated all of the *easy* ebuilds (those who had >=x11-libs/qt-3.0.0 -> =x11-libs/qt-3* ).
So KDE team, did we ever come to a consensus on how to handle this? Nobody seemed to really liked my $(qt_min_version) idea via the eclass. I've fixed most of the easy cases in portage now, but how to handle, for example: >=x11-libs/qt-3.3.3 I have renamed qt.eclass to qt3.eclass and I believe we can tell people to prefer using it over kde-functions/need-qt. Basically, set the depend for Qt explicitly within the ebuild, and the pkg_setup should handle setting QTDIR up for the user. I'd like to go ahead and start getting the ebuilds in portage fixed with this new scheme, but I want to make sure I don't have any problems with it before the transition starts...
To summarize: If an ebuilds uses kde-functions and need-qt(), it is changed to inherit qt3 instead and in *DEPEND it gets =x11-libs/qt-3*, if appropriate, or $(qt_min_version 3.x.y) if needed. If an ebuild uses kde-functions and set-qtdir(), it is changed to inherit qt3 and the qt versions in *DEPEND are changed in the same way. If an ebuild does not use kde-functions, the qt versions in *DEPEND are changed to =x11-libs/qt-3*, if appropriate, or it is changed to inherit qt3 and do $(qt_min_version 3.x.y), if needed. Right? That's ok for me, in case.
Sounds good. I think I'll open a new bug in the next few days to this regard and see if we can't get people to start using the qt3.eclass
I found a little problem: addwrite/addpredict do not work in pkg_setup, they must be in global scope or in a specific src_*. Maybe we can remove the has_version and move everything in pkg_setup() in global scope?
I committed the change to qt3.eclass as explained in previous comment.
Closing as fixed.
