| 1 |
Peter Humphrey schrieb am 21.10.2008 11:07: |
| 2 |
> On Monday 20 October 2008 13:08:30 Daniel Pielmeier wrote: |
| 3 |
>> Unmerge x11-libs/qt-4.3.3 and try again. If you want to be on the safe |
| 4 |
>> side do a quickpkg =x11-libs/qt-4.3.3 before. The new qt-4.4.x split |
| 5 |
>> ebuilds can not live alongside the non split ebuild. |
| 6 |
> |
| 7 |
> I ran quickpkg and emerge -C on qt-4.3.3, then emerge -upDvN world again. |
| 8 |
> The block is still there, exactly the same as before. |
| 9 |
|
| 10 |
Let me quote Alan here: |
| 11 |
|
| 12 |
> I main underlying reason seems to be that Qt now comes as split-ebuilds and |
| 13 |
> Peter has some monolithic ones installed. It's similar to migrating KDE to |
| 14 |
> split-ebuilds, but on a much smaller scale. Unfortunately there's no easy way |
| 15 |
> to automate this in an ebuild, that would require several new unrelated |
| 16 |
> packages replacing one big one, portage doesn't support that kind of thing. |
| 17 |
> So one has to do it manually, and deal with the resulting recdep-rebuild |
| 18 |
> issues as well .... |
| 19 |
|
| 20 |
The problem is that portage is probably not smart enough to do the |
| 21 |
upgrade from the non-split to the split ebuilds, so the world update |
| 22 |
will always run into this blocker even when qt-4.3.3 is not installed. |
| 23 |
Maybe some ebuild depends on >=qt-4.3.3 so it is pulled in and another |
| 24 |
one depends on >=qt-4.4.x which also gets pulled in and thus the |
| 25 |
blockers. This should be no problem in the normal case as the highest |
| 26 |
needed version would be installed. But the new split ebuilds have no |
| 27 |
relation to the old monolithic which is probably causing the problems in |
| 28 |
this case. The highest available version for monolithic is qt-4.3.3 and |
| 29 |
so it is pulled in alongside the new split ebuilds which are also needed |
| 30 |
because of a >=4.4.x dependency of other programs. |
| 31 |
|
| 32 |
I remember such problems to when migrating to qt split ebuilds and |
| 33 |
simply running emerge world was not enough but I do not remember the |
| 34 |
exact procedure which solved this. There were some issues with PyQt4 but |
| 35 |
I am not sure if this was related. One thing I would give a try is to |
| 36 |
give portage a hand and emerge some of the qt split ebuilds with the |
| 37 |
oneshot option. In your case the qt split ebuilds which are blocked: |
| 38 |
|
| 39 |
x11-libs/qt-script-4.4.2, x11-libs/qt-dbus-4.4.2, |
| 40 |
x11-libs/qt-qt3support-4.4.2, x11-libs/qt-sql-4.4.2, |
| 41 |
x11-libs/qt-gui-4.4.2, x11-libs/qt-svg-4.4.2, |
| 42 |
x11-libs/qt-test-4.4.2, x11-libs/qt-core-4.4.2, |
| 43 |
x11-libs/qt-webkit-4.4.2, x11-libs/qt-opengl-4.4.2 |
| 44 |
|
| 45 |
and then see if portage will be able to continue with the world update. |
| 46 |
|
| 47 |
> I've started building a new system from scratch on another disk, and I'm now |
| 48 |
> about ready to start installing KDE on it. Maybe a clean start is what I |
| 49 |
> need. |
| 50 |
> |
| 51 |
|
| 52 |
I think this could be solved without a reinstall but it is up to you. |
| 53 |
|
| 54 |
Regards, |
| 55 |
|
| 56 |
Daniel |
Archives