1 |
Alex Schuster wrote: |
2 |
> Roy Wright writes: |
3 |
> |
4 |
> |
5 |
>> kde-4.3 is now unmasked for ~x86. Whooooop! |
6 |
>> |
7 |
> |
8 |
> I'm also happy, and I want to upgrade soon. I hope many of those little |
9 |
> annoyances I experience will be fixed. |
10 |
> |
11 |
> |
12 |
>> But it is looking like a non-trivial upgrade. :( |
13 |
>> |
14 |
> |
15 |
> Yeah. |
16 |
> |
17 |
> |
18 |
>> When I installed kde-4.2, I followed the advice of unmasking portage |
19 |
>> and using sets. Also followed the recommendation to use -kdeprefix. |
20 |
>> Further I removed kde-3.5 and added a mask on kdelibs-3.5 to help keep |
21 |
>> 3.5 off of the system. |
22 |
>> |
23 |
>> So for the kde-4.3 upgrade, it looks like this is what will be |
24 |
>> necessary: |
25 |
>> |
26 |
>> 1) grab the sets again from the kde-testing overlay and put them in / |
27 |
>> etc/portage/sets (assumption is to do a replace). |
28 |
>> |
29 |
> |
30 |
> I did that, too, but got errors from portage (Error during set creation: |
31 |
> Redefinition of set...). Looks like the sets are found in the kde-testing |
32 |
> overlay, so I removed them from /etc/portage/sets, and all was fine. Coool. |
33 |
> |
34 |
> |
35 |
>> 2) unmerge kde-4.2 using: emerge --unmerge @kde-4.2 |
36 |
>> |
37 |
> |
38 |
> Not really necessary I heard. |
39 |
> But: I am still using the dreaded kdeprefix use flag. It sounded like a good |
40 |
> idea to use it, and I would also like to have different minor KDE versions |
41 |
> alongside. Okay, it's hard to maintain, I understand it will be dropped. |
42 |
> Now, do I REALLY REALLY have to unmerge all @kde-4.2 first, remove the |
43 |
> kdeprefix use flag, and proceed to step 3? |
44 |
> |
45 |
> |
46 |
>> 3) merge kde-4.3 using: emerge -av @kde-4.3 |
47 |
>> |
48 |
> |
49 |
> Hopefully this runs through. If it takes a night, it's okay, but if it stops |
50 |
> in the middle, I have no KDE for a while. And I need much of the stuff in |
51 |
> there, like the wallet with its passwords. |
52 |
> |
53 |
> What about this: I update my system's backup (I'm using rdiff-backup), |
54 |
> chroot into the backup, sudo to my account, and issue startkde. Could I get |
55 |
> a running KDE 4.2? Then I would have time to install 4.3. |
56 |
> |
57 |
> |
58 |
>> 4) recustomize kde as the ~/.kde will not be migrated |
59 |
>> |
60 |
> |
61 |
> I really hope I can just copy .kde4.2 to .kde4 and all (okay, most) settings |
62 |
> will be kept. I think it just _should_ work. Customizing all over again |
63 |
> every time a new KDE arrives would be no good. |
64 |
> |
65 |
> Wonko |
66 |
> |
67 |
> |
68 |
> |
69 |
|
70 |
Well, I don't know about necessary, but on my box, when I tried to |
71 |
update from kde-meta:4.2 to kde-meta:4.3, there were a few blockers that |
72 |
wouldn't let it go through, so I ended up unmerging 4.2, then emerging |
73 |
4.3 (which took about 4-6 hours, but I have distcc set up between two |
74 |
boxes, so that probably sped things up). However, I seem to remember |
75 |
that the blockers were with PyQt, Python and eselect-python; I hadn't |
76 |
thought about it, cause I'm still not THAT experienced with Linux in |
77 |
general, and Gentoo in particular, but the Python update was a Big Deal, |
78 |
so perhaps updating Python before the KDE upgrade would have been a good |
79 |
idea. :-P Granted though, I didn't use sets, so it may be a bit |
80 |
different for you. |
81 |
|
82 |
Oh, and I didn't touch my .kde or .kde4 folders during this process, and |
83 |
as far as I can tell, it's still using all of my customizations... |
84 |
|
85 |
--==**==-- |
86 |
John Moe |