Since KDE 3.4, kmail's default mail directory is at ${HOME}/.kde/share/apps/kmail/mail rather than ${HOME}/Mail. Within startkde, there is the following lines: if [ -e .kde3.4 ]; then cp -r .kde3.4 .kde3.5 As well as taking a very long time, this makes an unneeded backup of all of one's mail.
One point that I forgot to mention: the maildir location stored in kmailrc contains .kde3.4 in the path. Hence, if a user notices that .kde3.4 is taking up a lot of space after upgrading to 3.5 and deletes the directory, they'll lose all the mail and retain an old backup.
The problem in comment #1 should not happen, after the copy .kde3.4 -> .kde3.5 the references to kde3.4 should be changed to kde3.5. Can you confirm that this didn't happen for you? About the unneeded copy, power users that don't want it can use the (undocumented) trick of creating a real ".kde" directory in $HOME, KDE will then use just that directory and will not create others. What can be done in addition in your opinion?
Ah, I didn't get the 3.4 -> 3.5 update as I killed it after figuring out why logging in was taking so long. If that happens then it's not as bad, but still bad.. I assume the .kde3.x directories are so that users can use both versions at the same time. However, if they do actually use both versions it'd cause mail to be downloaded to different locations (and presumably deleted from the server as well). It seems to me that it's more the power user that would be jumping between kde versions, so perhaps it'd be better to default to using .kde rather than the versioned dirs? Not sure.. It wouldn't address the above issue either way. Don't really have ideas about what to do about the above.
(In reply to comment #3) > I assume the .kde3.x directories are so that users can use both versions > at the same time. However, if they do actually use both versions it'd cause > mail to be downloaded to different locations (and presumably deleted from the > server as well). No. Never downgrade the used KDE version or switch between them with the one and the same user. Create a extra user account when you want to test. KDE was never made to care for config and user data using multiple KDE versions in a sane manner. That the mail data gets copied now is suboptimal - that KDE keeps user data in the same directory structure as user configuration data is broken anyway imho - but I don't see what we can do about it.
So what is the purpose for versioning the user's config?
Good question. I'm less and less thinking it's a good idea, but as long you don't care much about your data, for testing purposes it's fine to switch between KDE versions with one user.
Since KDE 3.3 I remove Gentoo's versioning from startkde. There are no problems when you don't use diffrent kde-versions in parallel. I'd like to have versioning removed instead of editing every startkde - update ;-)
So we could make the startkde in 3.5 mv to .kde instead of cp and then use that in later releases?
We can't just move the dir over, because that'll actually break the kde3.4 session (or rather, erase its data and settings, causing its startkde to copy over 3.3's old settings...). Removing .kde versioning means there's a real .kde dir instead of a symlink, but we can't introduce this without upgrading the previous slots' startkde scripts first. Someone who's testing different kde versions usually has the ability to create separate users for separate versions. Even if he doesn't, it's trivial to create separate login scripts that set $HOME. (Or if shared per-user files in /tmp interfere, a chroot with mount-binds can help... What permissions does one need to run mount -o bind?...) A bit late just now, but I'm in favor of removing .kde dir versioning for at least kde4. It really doesn't seem to have that much value. If people want it, we can provide a separate ebuild with a startkde script or session defs that will provide the current behaviour.
(In reply to comment #7) > There are no problems > when you don't use diffrent kde-versions in parallel. Apparently you didn't run into problems caused by subtle configuration changes betweeen different versions of KDE applications, but that doesn't mean you can't break your config. (In reply to comment #8) > So we could make the startkde in 3.5 mv to .kde instead of cp and then use that > in later releases? For KDE 3.x I'm against any changes in this regard. (In reply to comment #9) > A bit late just now, but I'm in favor of removing .kde dir versioning for at > least kde4. It really doesn't seem to have that much value. If people want it, > we can provide a separate ebuild with a startkde script or session defs that > will provide the current behaviour. Well, it's some time until even KDE 4 betas will be out, but the problem will be the same: When multiple KDE 4.x sessions are chosable, some users will break their configuration, when switching forth and back. So either we keep only the session entry for the latest KDE version in future or we drop slotted KDE versions at all.
Right. In fact the lenghty discussion we had at the time of the 3.4 release was that we should keep the current system for now to avoid doing more harm than good, and to rethink the whole strategy about .kde and kde slotting in kde4. One thing we did in the startkde script since 3.4 was to make the script do nothing in case ~/.kde exists and is a real directory, to ease the transition if we wanted to make .kde a real directory for kde4. So this can be exploited already to avoid the copy .kde3.4 -> .kde3.5 as explained in comment #2.
Dead old bug, there won't be any new slotted KDE 3.x release and for KDE 4 we should better drop that and install KDE 4 in an FHS compliant path.