Bugzilla Bug 97404

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.