| 1 |
On Saturday 02 July 2005 22:54, Caleb Tennis wrote: |
| 2 |
|
| 3 |
|
| 4 |
> While your proposal works okay for the qt4 scenario, I'm more concerned |
| 5 |
> with the existing qt3 at the moment. As is, I stil l don't see a way |
| 6 |
> around what has been proposed for those ebuilds. Until portage has the |
| 7 |
> ability to handle && deps, I fear there's no real way around it. I don't |
| 8 |
> think we'll have time to wait much longer; I expect ebuilds that need qt4 |
| 9 |
> will start appearing in portage soon and the minute that qt4 is marked |
| 10 |
> ~arch it instantly creates the dependency mess addressed previously. |
| 11 |
|
| 12 |
We can start porting those ebuilds that just need to be changed using |
| 13 |
"=x11-libs/qt-3*". Then we can change kde-functions.eclass for the ebuilds |
| 14 |
using need-qt() (which can set something like e.g. || ( =x11-libs/qt-3.3* ... |
| 15 |
=x11-libs/qt-3.1* ) ); and finally we can deal with the remaining ebuilds |
| 16 |
(not many probably) using the qt.eclass (or qt3.eclass, or qt3-info.eclass, |
| 17 |
or whatever), or again something like "|| ( =x11-libs/qt-3.3* ... |
| 18 |
=x11-libs/qt-3.1* ) )" where possible. |
| 19 |
-- |
| 20 |
gentoo-dev@g.o mailing list |
Archives