I am seeking advice for migrating to KDE4.

I apologize for the long post, but this will be a serious migration.

When Current goes official I plan to install and give KDE4 a serious run. Because I am running 12.2 I will forego the upgrade path and install fresh in separate partitions. I haven't performed a fresh install since first installing Slackware 10.1. Likely I'll go 64-bit as my system is a dual core AMD with 4GB of RAM. Is there a list somewhere of 32-bit apps that have no 64-bit versions? I don't think I am using any such apps but a list would help.

Through the years I have many system tweaks and customized settings, but I'll be able to migrate and resurrect those readily. Mostly I am concerned with the desktop migration.

Any punch list of warnings and "gotchas" are welcomed. I appreciate any links focusing on migrating at such a "late" stage in the KDE4 cycle.

I don't want to build the desktop completely from scratch. A fresh install reduces cruft and clutter that might have accumulated through the years, but also means more work configuring the desktop and apps. Fortunately, I long ago housed my user and data file directories on separate partitions and don't have to worry about that.

I want to move through this patiently. Therefore during the transition I will be dual booting but using the same user accounts. All user accounts currently have $HOME/.kde profile directories that I do not want clobbered by KDE4. Should I rename that directory now and change a handful of KDE environment variables in 12.2 before working with KDE4, such as $KDEHOME and $KDE_CONFIG_DIR? New user account names would be one option, but my primary user account has too many non-KDE settings to migrate.

In that spirit, would somebody post the default Slackware KDE related environment variables so I can compare to those in KDE3?

I am browsing the forum and web for various elements I should know or be forewarned, but many of the threads are old and I suspect no longer apply to KDE 4.5.5. I would like to migrate as many KDE 3.5.10 settings as possible, such as KMail, Akregator, Kate, Konsole, KMix, K3B, Kaffeine, Amarok, Digikam, etc. I realize there might be a point of diminishing returns and reconfiguring from scratch might be less problematic.

Will both KDE4 and KDE3 be able to use the same KMail files? Or during the transition should I restrict my mail checks to KDE3? I don't want to deal with indexing issues or other such problems.

If possible I would like to disable Nepomuk and Strigi before starting my first session in KDE4. I don't want to disable them after starting the first session as then profile files are automatically created. Hopefully nothing more than editing some default configuration files (/usr/share/autostart? Don't install those packages?). I have no need for or interest in Nepomuk (social-semantic desktop). I don't think I have any use for Strigi, which if I understand correctly, focuses on indexing meta data rather than just finding files. As far as I can tell because of PIM apps, disabling Akonadi is futile, so I won't try.

Thanks again.

Although I've not used KDE regularly for some time, I can share some of my experiences in performing the same upgrade.

I think the idea of trying to base a 4.x install off of a 3.x .kde is not going to be easy. I don't know exactly where the problem lies, but KDE 4.x simply does not like the old configuration files. In fact, I suspect trying to reconfigure everything based on the old files will be much more of a challenge than just reconfiguring.

However, most of the applications will not require reconfiguring. After backing up your .kde, I'd remove the .kde/share/config directory completely, and then pick out the applications of .kde/share/apps that you definitely want to preserve. You can then copy over the rc files from the backed up .kde/share/config which are used by those particular applications in order to keep as many settings as possible. In any case, a little trial and error should be all that is needed to isolate any applications which don't migrate well. I can't think of any notable cases of applications that fall into this category. Personally, I recall being most concerned about retaining my Kontact (including all my KMail), Amarok and Kwallet settings, and this proved to be very easy for me at the time. One thing to remember is that KMail has not undergone a major version change between KDE 3.x and 4.x.

It is also easy to turn off Nepomuk and Strigi through KDE's settings, though Slackware also adds some Nepomuk stuff to /usr/share/autostart that I always remove. Akonadi shouldn't be a bother, though one version of Slackware suffered from the problem of Akonadi not starting on log in and this would cause Kmail to complain. Should you come up against that, just create your own Autostart entry in System Settings and you will be fine. I don't believe this is an issue in Slackware's KDE 4.5.

Good luck!

After a lot of reading yesterday I got the idea that copying the ./kde/share/apps files probably was safe. That will help with KMail, Akgregator, Amarok, etc. I had resigned to building new .kde/share/config files, but you imply I might not have to do this for some of the app related rc files. I'll keep that in mind. I did expect not to transfer rc config files related to the overall desktop.

Okay, edit /usr/share/autostart files before running that first KDE4 session. Thanks.

Does KDE4 use a profile directory of $HOME/.kde or $HOME/.kde4? /etc/kde or /etc/kde4?

$HOME/.kde by default (you can of course change this by exporting $KDEHOME) and /etc/kde (I don't know how to change this one...not sure if you'd need to recompile or if you can export something similar).

It isn't important that the autostart files be modified before your first session; they can be removed or added whenever you like. But there are a few KDE elements which Slackware runs automatically whenever you log in, one of which is Nepomuk related. This is off the top of my head, but you can also find kmix, wicd, knemo, kalarm and a few others in there. I just move the ones I am not interested in out of the directory to a back up location, though there probably is a way of modifying the files themselves to disable their behaviour.

/etc/kde can be controlled with the $KDE_CONFIG_DIR environment variable. I'm thinking that because I intend to dual boot for several weeks rather than try a mind boggling cold turkey, I might reset those variables now in 12.2 and add a few lines in my global /etc/bashrc to distinguish between the two desktops. That way when I install Current/13.2/Whatever and KDE4, I won't have to mess with the default variables.

Maybe then like I should run a handful of installation attempts to fine-tune the environment: Run with the defaults, reconfigure/remove the apps I don't want, remove any associated rc files, and then copy those settings to /etc/skel. Probably better that way because the files in /usr/share/autostart will be overwritten with any subsequent package patch or update. I could build my own custom packages but that could become a never-ending hassle. I just want to avoid the cruft of rc files being created and avoid the overhead of Nepomuk and Strigi.

As I'm not at my Linux box, I can't check, but I believe that the autostart Nepomuk program might be more like a service which won't actually create any files in .kde until KDE's actual Nepomuk/Strigi kicks in. The problem (as it were) is that on your first start of KDE, Nepomuk and Strigi are enabled by default irrespective of what is in autostart. This means that you will get a couple of unwanted rc files since by the time you go into SystemSettings, they will both have been initialised. However, deleting the Nepomuk/Strigi files in share and apps after this will be permanent. I don't believe the autostart Nepomuk thing (whatever it is) will regenerate them. Or maybe it does. It's been a long time. And yes, later updates will regenerate the autostart files. But they are not resource intensive. I only became curious because I could still see a Nepomuk process despite having deactivated it. As it turned out Slackware is configured to start it automatically even if it is disabled in KDE. I definitely wouldn't go to the trouble of rolling my own packages over it.

I've never used skel myself, but if you are trying to create a standard KDE desktop for multiple users, I shouldn't think that it will be too time consuming to do it that way.

I have read this elsewhere, so I'm unsure this is limited to Slackware. From what I have read, I'm unsure that the Nepomuk process is explicitly started. I get the feeling that something else in KDE starts and that starts the Nepomuk process.

In all this might be a never-ending uphill battle. Although there are options to disable, seems the processes still get called and run. I wonder whether disabling the executable bit for Nepomuk might help.

Strigi seems the simplest to disable --- just don't install the package. Too bad Nepomuk is not a separate package.

Well, there are two different Nepomuk executables. One is started by the KDE indexing service and one is started from the autostart directory. I can't say for sure, but I believe the contents of autostart have been deliberately selected for Slackware as a design choice.

In any case, I don't think the 'problem' of Nepomuk should be overstated. It is trivial to disable Nepo/Strigi in KDE, and this will achieve exactly what you want. Modifying autostart won't change much except kill an unneeded process which won't be doing anything anyways.

Dont know if you've seen these:

http://lxer.com/module/newswire/lf/view/144200/
http://lxer.com/module/newswire/lf/view/144900/
http://lxer.com/module/newswire/view/146439/

Maybe they will help you migrate.

Yes I have. Thank you.