| 1 |
On Sun, Jul 5, 2015 at 2:25 PM, Sebastian Pipping <sping@g.o> wrote: |
| 2 |
> |
| 3 |
> |
| 4 |
> I really wonder if there is any update path from having |
| 5 |
> |
| 6 |
> dev-qt/qtcore-4.8.6-r2 |
| 7 |
> dev-qt/qtgui-4.8.6-r4 |
| 8 |
> |
| 9 |
> installed before to |
| 10 |
> |
| 11 |
> dev-qt/qtcore-4.8.7 |
| 12 |
> dev-qt/qtgui-4.8.7 |
| 13 |
> |
| 14 |
> |
| 15 |
> |
| 16 |
> Usually this kind of conflict happens when for SOME reason, at least one |
| 17 |
part of the dev-qt/*:4 collection is not being pulled into the depgraph, |
| 18 |
like if there's one qt* package which is now orphaned/depcleanable. If |
| 19 |
even one piece is not pulled into the dep list, it will try to hold all the |
| 20 |
rest of the pieces back at 4.8.6. |
| 21 |
|
| 22 |
Something like this may help, to just force all installed qt4 pieces to |
| 23 |
upgrade, regardless of whether they are deps of anything: |
| 24 |
|
| 25 |
emerge -1av $(qlist -ICS dev-qt/ | grep 4$) |
| 26 |
|
| 27 |
Another possibility for a conflict is if you have some package.use entries |
| 28 |
for dev-qt/ that are too version specific, where the upgraded 4.8.7 version |
| 29 |
of some component would not meet the USE requirements of some reverse dep. |
| 30 |
Then it'd lock that one component at 4.8.6 and again it's game-over for the |
| 31 |
upgrade. |
| 32 |
|
| 33 |
Hope this helps, |
| 34 |
Ben Kohler |
| 35 |
(iamben @ Freenode) |
Archives