There's a nasty bug caused by Gentoo's startkde-3.2.0-gentoo.diff patch. Gentoo puts KDE's dotfiles into ~/.kde$VERSION instead of ~/.kde and makes ~/.kde a symlink. This becomes a problem when upgrading to next major release, because several dotfiles contain absolute filenames of some files under ~/.kde and they are stored in the form _after_ resolving the ~/.kde symlink (for example, "/home/vasek/.kde3.1/share/apps/kabc/std.vcf" instead of "/home/vasek/.kde/share/apps/kabc/std.vcf"). This silently breaks some applications (exact details are unknown to me, but they obviously have problems finding and/or updating the data). Following files are affected on my system: vasek@wintermute .kde3.2 $ grep -r '\.kde3\.1' * share/apps/kabc/distlists:[/home/vasek/.kde3.1/share/apps/kabc/std.vcf] share/apps/kalarmd/clients:Calendar1=1,,file:/home/vasek/.kde3.1/share/apps/kalarm/calendar.ics share/config/kabcrc:FileName=/home/vasek/.kde3.1/share/apps/kabc/std.vcf This demonstrates itselfs in two ways: KAddressbook (kabc files) will not show any stored distribution lists and KAlarm won't trigger alarms setup before the upgrade. KAlarm will add another client line to its file above and only alarms from this new file will be triggered. Changing these occurences of ".kde3.1" to ".kde3.2" fixes both applications. No problem would occur if ~/.kde weren't a symlink. Reproducible: Always Steps to Reproduce: 0. Add a distribution list to KAddressbook, setup an alarm in KAlarm 1. Umerge KDE 3.2.0 2. Don't delete ~/.kde3.1, start KDE, ~/.kde3.1 will be copied to ~/.kde3.2 3. You will not find any distribution lists in KAddressbook anymore, alarms added before upgrade won't trigger
I believe if we add a line in startkde.diff that when it creates the .kde3.2 directory by coping .kde3.1 files into it, if we do a search and replace for all instance of .kde3.1 -> .kde3.2 that would fix the problem. I just need to put on my "sed" thinking cap a bit.
Unless some dotfile contains ".kde3.1" in other context (like lastfile=/tmp/myfile.kde3.1 or someMagicTagThatYouMustNotChangeOrAppFooWillBreak=.kde3.1), in which case you are going to break *that*. You could check for "/home/user/.kde3.1", but that's not safe either (think "/var/backups/home/user/.kde3.1"). If you decide to do something like that, it's probably good idea to let the user know about it when it happens, so that if the script changes something it shouldn't, the user has a clue about what caused it.
Same problem when upgrading from 3.2 to 3.3, unsurprisingly. The only difference: there are even more places that are affected.
Well, there's indeed a lot of stuff broken after the update. Especially if someone tries to remove the old .kde3.2 directory.
Caleb: I simply did `find ~/.kde -type f -exec sed -i -e "s:\.kde3\.2:\.kde3\.3:" '{}' \;` and I had no problem with it so far, but I'm using kde3.3 already and don't have a "used" ~/.kde3.2 at hand. Also there may be other side effects, I'm not aware of. What do you think?
Yes, this is exactly what we need. I tried this a long time ago but was unable to come up with the correct sed syntax to make it work and finally gave up. Please commit! :)
> Also there may be other side effects, I'm not aware of. What do you think? See comment #2 on why it's not good idea.
Perhaps, but it I would bet that it fixes a lot more than it breaks. Right now, most people end up having to clear out .kde anyway.
Yes, but when it breaks, it will be extremely hard to track down (this bug itself was nasty enough...). That's why I think that it would be better to either do something smarter (substitute only known occurences or don't mess with ~/.kde to begin with) or to notify the user after doing this replacement, e.g. via a popup box.
we can notify via portage ewarn message in the eclass.
>See comment #2 on why it's not good idea. If KDE provides no version independent variable for the user config path, then it's a flaw within KDE. If it does and applications do not use it and hardcode the path instead, then I consider them to be broken. Sure, this doesn't really help in a special case, and I'm a bit astonished, that I did not run into such a problem after a week of testing, but please tell me: What else we could do?
> If KDE provides no version independent variable for the user config path, then > it's a flaw within KDE But KDE provides version independent user config path (~/.kde), it's Gentoo who changes it into ~/.kde-$version. If you mean that it's a flaw that all KDE versions use ~/.kde, then it's a matter of opinion -- I for one would disagree, I regard it as better than using ~/.kde-$version or whatever. Besides, KDE *does* provide a way to change the config directory, if you really need it: the KDEHOME environment variable. (If you meant something else, I didn't understand you.) > If it does and applications do not use it and hardcode the path instead, then > I consider them to be broken Some apps store absolute path to a data file and this file happens to live under the ~/.kde directory. Since the directory is *always* ~/.kde and doesn't change between KDE versions in unpatched KDE, I don't see how can you consider the apps broken. They work correctly in stock KDE installation, it's the *Gentoo patch* that breaks them! They assume something that is known to be valid assumption in KDE, but Gentoo changes the behaviour in such way that the assumption no longer holds. > and I'm a bit astonished, that I did not run into such a problem after a week > of testing Apparently, you don't use the affected apps and/or features. > What else we could do? Not apply patches to KDE that break it?
So then you suggest that upon an upgrade of a kde version we just change KDEHOME to point to a new location? The only problem is that your configuration options from the previous version wouldn't be used.
No, I don't (I only mentioned KDEHOME in reply to comment that seemed to imply that this is somehow a KDE fault). I suggest that that the best would be if you didn't break KDE by applying a broken patch to begin with. If you need different dirs for different KDE versions for whatever reason, do it in some way that doesn't break apps, e.g. by keeping all the data in ~/.kde (as it is in unpatched KDE) and having ~/.kde-$version a symlink to ~/.kde (i.e., the the reverse of current situation). Then, when startkde is executed, it would find the ~/.kde-$version symlink that points to ~/.kde, remove it, rename ~/.kde to this ~/.kde-$found_old_version (at this point, you would have several ~/.kde-$version dirs and no ~/.kde). Then, rename ~/.kde-$this_version (i.e. data of the version that startkde script being executed belongs to) to ~/.kde and make a ~/.kde-$this_version symlink to it (so that you know from which version did ~/.kde come from next time startkde is run). To summarize it, when you run KDE, dotfiles of currently running KDE version would be stored in ~/.kde and dotfiles for other versions would be in ~/.kde-$version directories (e.g. ~/.kde-3.1, ~/.kde-3.2 and ~/.kde with 3.3's files). When you run a different version of KDE, the dirs would be reorganized to maintain the above invariant (e.g. by changing the dirs into ~/.kde-3.1, ~/.kde and ~/.kde-3.3). This way, you can still have multiple copies of dotfiles around _and_ have ~/.kde as real directory, thus preventing any problems (because such ~/.kde would be what stock KDE does and all apps expect it). A simple ~/.kde -> ~/.kde-$version symlink is surely simpler easier to implement, but this scheme has the advantage that it doesn't break apps that assume ~/.kde is a real directory.
Can I vote for this bug? Can I say that I would really, really, really like to see Vaclav Slavik's suggestion made true? Can I report that after the first run of KDE 3.3, the Gentoo script copied ~/.kde3.2 into ~/.kde3.3 AND to ~/.kde3.3/.kde3.2, so that my KDE settings took thrice the space they required in my home, filling my / directory in the process AND not working (empty KAddressBook, etc...)? Please, I know I may sound a bit angry, I'm just disappointed. :-( I remember that Gentoo's patching policy was to fix what was broken, not to break things up. :-( Especially comments like #8 ("it will fix more than it breaks") make my heart ache. :-(
There is definitely something wrong with the current startkde (kde-3.3.0). 1) Why are there two /bin/cp -r .kde3.2 .kde3.3 commands inside the if [ ! -e .kde3.3 ];? This triggers the behavior described in comment #15. 2) The /bin/ln -sf .kde3.3 .kde seems to create a dangling link _inside_ .kde3.3???? Can anybody explain that to me????
*** Bug 65897 has been marked as a duplicate of this bug. ***
the last KDE (3.3) in portage has tooo many errors. problems with kde upgrade, kate, kmail, korganizer,... why is in heaven's sake in portage as stable??? :(((((((((((
What about this for now, so we can go back thinking to the sed line: +# Gentoo part: +export PATH="_KDEDIR_:${PATH}" +export KDEDIR="_KDEDIR_" +# Use env.d's KDEDIRS. They should only include locations like /usr though, not +# actual KDE installations + +# handle ~/.kde* dirs - separate ones for separate KDEs +cd ~ +if [ -e .kde ]; then + if [ ! -L .kde ]; then + /bin/mv .kde .kde.backup + else + rm -f .kde + fi +fi +if [ ! -e .kde3.3 ]; then + if [ -e .kde3.2 ]; then + /bin/cp -r .kde3.2 .kde3.3 + else + /bin/mkdir .kde3.3 + fi +fi +/bin/ln -sf .kde3.3 .kde + +#export KDEHOME="${HOME}/.kde3.3"
in kdebase 3.3.1, the patch has been changed to read like what is in #19
*** Bug 67193 has been marked as a duplicate of this bug. ***
Thanks. I was thinking that it should be /bin/mv -f .kde .kde.backup instead of /bin/mv .kde .kde.backup just to be on the safe side...
changed.
I noticed that all the lines I had to change manually where in the form "$HOME/.kde3.2/foobar". Maybe that would help in constructing the sed-statement?
Antti: It's fixed for 3.3.1. For a sed expression, see comment 5. Worked fine for me.
I tried the sed statement in 5. However, Really long lines in config files caused problems, ie. not all references changed. I could correct this by adding "-l 10000" to the sed command.
sed is limited to 4096 chars iirc.
*** Bug 68910 has been marked as a duplicate of this bug. ***
I think that this bug isn't solved. Am I right? What about the suggestions on Comment #14? I think this must be fixed before kde 3.4 is out.
Created attachment 48123 [details] startkde for 3.4.0_beta1 This is my startkde for 3.4.0_beta1 which should fix this bug. It implements the solution from comment #14, except that instead of using a symlink .kdeX.Y -> .kde I just echo 3.4 > .kde-cur, snice that's easier to manage when you need to find out what KDE is running from script. It also seds files to fix existing breakage on the 3.3->3.4 upgrade. However, I only change known files, to avoid breaking stuff. Please add more files to this list. Fex., I couldn't make kaddressbook store a hardcoded path in its configfiles - but I don't use it normally, and didn't try very hard.
> sed -i -e "s:$HOME/.kde3.3:$HOME/.kde3.4:g" > -e 's:$HOME/.kde3.3:$HOME/.kde3.4:g' ".kde/$file" shouldn't it be sed -i -e "s:$HOME/.kde3.3:$HOME/.kde:g" -e 's:$HOME/.kde3.3:$HOME/.kde:g' ".kde/$file"
Created attachment 48131 [details] startkde for 3.4.0_beta1 Oops. Fixed.
Does this fix work with KDM? Or should I say, does /etc/init.d/xdm script by-pass your fix? Everything was fine for me using `startx` but once I enabled kdm, I lost my settings again. I had to symlink .kde3.4 to .kde/
You probably need to remove the old code in /etc/X11/Xsetup_0 for this to work cleanly. Bug 80225 tracks the removal of that code from the xorg-x11 package. If that doesn't work for you, please provide more details on what breaks, how and why.
I'm having problems with the implementation from kde-3.4.0_beta2: Starting KDE via kdm works fine, the directories are copied as expected, _but_ when logging out, a skeletal .kde-directory is created (and the right one is copied back to .kde3.4, as expected). The result is, that, when logging on again, all settings are lost, I have to log out, manually delete the .kde-directory, so that the startkde-script can copy the right .kde3.4-dir back. I don't know why this happens (i.e. why this .kde-thing is created out of nowhere), but if you need further information, just ask :)
sorry for making too much noise .. after remerging startkde, the problem has disappeared. At least I hope it does not resurface. So forget it for now, seems to work.
netz: I made a patch (and I've in mind another one) that will fix some issues. the other kde devs are already aware of my ideas. Probably your issues are related to the problems I noticed.
actually it has happened again twice, yesterday. I'll remerge today and tell you if it happens again. It's a bit strange, sometimes it happens, sometimes not ..
I just find moving the .kdeX.Y dir arround may break kde apps running outside KDE. Say, if you are running GNOME and want to use amarok to listen to mp3, it will startup without configurations, because it can not find ~/.kde, because startkde script have moved it back to .kdeX.Y..... Any idea on how to fix this?
That's true - right now it's almost impossible to use a kde-app from another windowmanager. Concerning the ever reappearing .kde-folder - it has happened again (and does so quite regularly, though not always). One thing I forgot to mention: it does only contain empty the .kde/share/config - directory, nothing else. So I have no clue how it could be created .. but perhaps you have? :)
Is this now fixed for KDE 3.4 final release?
We came back to the use of the .kde symlink to .kdeX.X dirs. It's the better implementation also if it has some unfixable problems. The unique way to really implement multiple kde versions is to directly change the code of KStandardDirs and use it to manage the multiple configuration dirs. Changing the startkde script will work only if it's launched before any application of the new kde version installed. If someone launch directly a new kde program (from for example another WM) it will create its .kde dir as it's the first time its launched breaking the startkde gentoo's implementation.
Yes, but is the original problem (ie. hard paths inside kde config files) solved now (with sed or whatever you have decided upon?) so that when KDE 3.4.0 (or 3.4.1, not sure I want to upgrade to .0-release) is deemed stable I can upgrade without worries and everything still works? 3.2 -> 3.3 required quite a bit of find&replacing in every user's config directory even with the sed hint...
We cannot fix all the problems as we cannot know all the possible problems due to the large number of possible configurations. There's some sed magic inside the startkde that should fix a lof of issue. I personally didn't had any problem switching from kde 3.3 to kde 3.4 You are saying that you have to fix a lot of things by hand right? So why doesn you don't provide us which are the lines that you have to fix after updating to 3.4 so we can take a look at them?
So the sed magic *has* been included in startkde. That's all I was really asking for, thanks. I'll post my experiences and/or possible problems when I have time for a test upgrade (this weekend?).
Tried the upgrade to 3.4. Unfortunately the sed magic does not seem to work.. at least completely. First, references to $HOME/.kde3.3 was still left in quantarc. Also, I still have numerous references to /usr/kde/3.3/xxxxxx in the files - mostly to stuff like bundled themes, sounds etc. Since I'm going to uninstall 3.3 anyway, these should be changed to point to 3.4 versions - the automatic process did not do this for me. Going to do some sedding on my own then. Immediate effect that I noticed after upgrade was that my font settings in Konsole were gone.
If you want to help us, please save your old config so you can experiment with it and let us know which actions you did to fix the config files.
Ok, first of all, share/config/quantarc should be added to the list of files that are sedded in the current startkde version. (for file in ....statement). This fixes all references to config files that happened to me. However, in addition to that, all references to /usr/kde/3.3/ should be replaced with /usr/kde/3.4/. I find these references at least in share/config/kandyrc share/config/noatunrc (references to default presets) share/config/kickerrc (references to shortcuts for applications, such as "DesktopFile=/usr/kde/3.3/share/applications/kde/Home.desktop" share/config/amorrc (default theme) share/config/kmidrc (default midi map?) share/config/katesyntaxhighlightingrc (Whole lots of references to default xml files) share/config/khelpcenterrc (Cached glossary location) In addition, lots of other files have references, but they are in nature of "Recently accessed files/urls". Not sure if these should be updated - but I'm going to that myself, anyway. Examples include share/config/kcmshellrc:Recent Files=/usr/kde/3.3/share/apps/kicker/wallpapers/d efault.png,/usr/kde/3.3/share/apps/kicker/wallpapers/rail.png,/usr/kde/3.3/share /apps/kicker/wallpapers/deck_plate.png,/usr/kde/3.3/share/apps/kicker/wallpapers /green_line.png I could fix all of these with simply saying sed -i -e "s:/usr/kde/3.3/:/usr/kde/3.4/:g" -e 's:/usr/kde/3.3/:/usr/kde/3.4/:g' * in the config dir - maybe more careful handling should be conducted.
*** Bug 86657 has been marked as a duplicate of this bug. ***
Antti M
Antti Mäkelä: Your problems are quite different from the one we tried to address. We tried to fix the problems related to the change of the kde config dir (from .kde3.3 to .kde3.4) Your problems are instead related to the fact that some configs file save the full path of some installed files and their path chenged between versions. Probably we should try to address also these in the startkde scripts.
At this point, I think we should evaluate the possibility of sedding in a more general way, probably the advantages are more than the problems: cd .kde3.4 for file in share/apps/kdevdocumentation/search/htdig.conf \ share/apps/kalarmd/clients \ share/config/kresources/calendar/stdrc \ share/config/*rc; do if [ -e "${file}" ]; then sed -i -e "s:$HOME/\.kde3\.[23]:$HOME/\.kde3\.4:g" \ -e 's:$HOME/\.kde3\.[23]:$HOME/\.kde3\.4:g' \ -e 's:/usr/kde/3\.[23]/:/usr/kde/3\.4/:g' \ "${file}" fi done What do you think?
It seems to me that the hypothetical case of a *rc file containing ~/.kde3.3 which nevertheless shouldn't be sedded like this is sufficiently unlikely. Even if we break it somehow, it'd be broken anyway in the upgrade to 3.4. Actual data (as opposed to user settings) doesn't live there anyway, so the worst would be an app refusing to start. But that's very improbable.
The "full path of installed files" is definitely something that should be addressed. Lots of stuff breaks when after upgrade I remove (prune) the earlier KDE version.
Committed kdebase-3.4.0-r1/kdebase-startkde-3.4.0-r1 with the migration script changed as in comment #51. Please try to test them on some migration scenario, we need to have them in decent shape at the time kde-3.4 goes stable (which shouldn't be too far).
Gregorio: I have nothing to test, but the broken config entries I backed up when switching from 3.3 to 3.4 would be all fixed.
No more reports of problems related to this bug... closing.
(In reply to comment #50) > Your problems are instead related to the fact that some configs file save the >full path of some installed files and their path chenged between versions. > > Probably we should try to address also these in the startkde scripts. Anyone want to create a new bug report that addresses this since this is now closed?
(In reply to comment #57) > (In reply to comment #50) > > Your problems are instead related to the fact that some configs file save the > >full path of some installed files and their path chenged between versions. > > > > Probably we should try to address also these in the startkde scripts. > > Anyone want to create a new bug report that addresses this since this is now > closed? These problems were addressed in comment #51, or I am missing something?
Ah, I missed comment #54 (I just saw the closed-notification so I assumed that only the configuration files were being migrated). Well, great that this is finally done.
I'm still finding that my toolbars are not migrated, is this related to this bug? I just upgraded from kde 3.3.2 to 3.4.1 and the customisations to the KMail toolbar have disappeared, it's reverted to the default.
You changed XSESSION in /etc/rc.conf to kde-3.4 so the startkde script updated your config?
I don't use XDM. I've been using startx from the command prompt, and have /etc/X11/xinit/xinitrc call startkde. (I've also noticed that my calendar doesn't seem to have been brought along either, but my address book was.)
