1 |
Hi, thanks for you advice. I follow them and was able to fix the |
2 |
problem, its seemed that i had to add to unmask PyQt4 to allow |
3 |
installing 4.4.2 |
4 |
|
5 |
Best Regards Sebastian Geiger |
6 |
|
7 |
Duncan wrote: |
8 |
> Sebastian Geiger <sbastig@×××.net> posted 48FD9E6A.6060809@×××.net, |
9 |
> excerpted below, on Tue, 21 Oct 2008 11:18:34 +0200: |
10 |
> |
11 |
>> i am getting a blocks package xy error, as you can see from my pastebin: |
12 |
>> |
13 |
>> http://rafb.net/p/tPjaUP71.html and |
14 |
>> |
15 |
>> http://rafb.net/p/G6e9ML21.html |
16 |
>> |
17 |
>> Any ideas what i should do? Im not sure if i should remove qt-4.4.2 |
18 |
>> since kde4 depends on it, doesnt it? |
19 |
> |
20 |
> Well, yes and no. As KDE itself, qt-4 (or at least 4.4.2+, I'm not sure |
21 |
> about earlier qt4 versions) is now split packages. kde-4.1.2+ depends on |
22 |
> the various specific split packages, not on the qt-4+ meta-packages |
23 |
> themselves. Thus, removing qt-4.4.2 /should/ be fine, as long as you are |
24 |
> just removing the meta-package, not the components thereof. |
25 |
> |
26 |
> FWIW, I have much of kde-4.1.2 (as well as 3.5.10) merged here, and |
27 |
> here's what equery spits out for qt: |
28 |
> |
29 |
> ~$equery l qt |
30 |
> [ Searching for package 'qt' in all categories among: ] |
31 |
> * installed packages |
32 |
> [I--] [ ] dev-libs/dbus-qt3-old-0.70 (0) |
33 |
> [I--] [ ~] x11-libs/qt-3.3.8b (3) |
34 |
> [I--] [ ~] x11-libs/qt-core-4.4.2 (4) |
35 |
> [I--] [ ~] x11-libs/qt-dbus-4.4.2 (4) |
36 |
> [I--] [ ~] x11-libs/qt-gui-4.4.2 (4) |
37 |
> [I--] [ ~] x11-libs/qt-opengl-4.4.2 (4) |
38 |
> [I--] [ ~] x11-libs/qt-qt3support-4.4.2 (4) |
39 |
> [I--] [ ~] x11-libs/qt-script-4.4.2 (4) |
40 |
> [I--] [ ~] x11-libs/qt-sql-4.4.2 (4) |
41 |
> [I--] [ ~] x11-libs/qt-svg-4.4.2 (4) |
42 |
> [I--] [ ~] x11-libs/qt-test-4.4.2 (4) |
43 |
> [I--] [ ~] x11-libs/qt-webkit-4.4.2 (4) |
44 |
> $ |
45 |
> |
46 |
> Note that I have a number of the qt-*-4.4.2 components merged, but not |
47 |
> the qt-4.4.2 metapackage itself. If I do a pretend emerge qt, it wants |
48 |
> to install two additional components (qt-xmlpatterns and qt-assistant) of |
49 |
> the metapackage I don't really need, before installing the metapackage |
50 |
> itself. |
51 |
> |
52 |
> So unmerging qt-4.4.2 should be fine, as long as all you unmerge is the |
53 |
> metapackage. You'll probably want to do a --depclean after that, and |
54 |
> unmerge the couple of likely unnecessary additional components, too. Of |
55 |
> course, the usual warning before doing a depclean (or before removing the |
56 |
> --pretend) applies. Make sure you've done an emerge update newuse world |
57 |
> first, and that revdep-rebuild doesn't list anything needing rebuilt. |
58 |
> |
59 |
> Hopefully that solves the blocker, but I'm not sure. I don't have PyQt4 |
60 |
> installed, only PyQt-3.17.4. Obviously, I don't have anything merged |
61 |
> that needs PyQt4. Thus, I don't know its dependencies. Well, let me |
62 |
> look... |
63 |
> |
64 |
>>From what I see here, you should be fine, tho it's possible you'll need |
65 |
> to remerge PyQt4 as well. An emerge pretend PyQt4 wants to install |
66 |
> -4.4.3 here, and it doesn't throw up any blockers. So hopefully, once |
67 |
> you unmerge the metapackage, you'll be fine. If not, it's likely in your |
68 |
> use flags. Try playing around with them and see if you can avoid the |
69 |
> blocker. I know I had to do that almost a year ago when I was playing |
70 |
> with the kde4 pre-releases, but I gave up when I saw 4.0 wasn't going to |
71 |
> be anywhere close to a 3.5 replacement for me, until 4.1.2 hit the tree |
72 |
> not long ago. Thus, it's likely I already had my USE flags setup not to |
73 |
> conflict this time, due to having worked it out way back then. |
74 |
> |
75 |
> Also note that I don't have /all/ of the kde-4.1.2 metapackage merged. I |
76 |
> have most of the first level components (kdebase, kdegames, etc) merged, |
77 |
> but even there, I used set negation to avoid some of the packages I knew |
78 |
> I'd not use. So it's possible you have packages with additional |
79 |
> dependencies merged, thus creating blockages I'm not seeing, even if your |
80 |
> USE flags matched mine 100%, which is unlikely. |
81 |
> |