Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 104679 - KDE 3.4 -> 3.5 transition copies kmail's maildir
Summary: KDE 3.4 -> 3.5 transition copies kmail's maildir
Status: RESOLVED WONTFIX
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] KDE (show other bugs)
Hardware: All Linux
: High major (vote)
Assignee: Gentoo KDE team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-09-03 00:10 UTC by Jason Stubbs (RETIRED)
Modified: 2007-04-25 15:49 UTC (History)
4 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jason Stubbs (RETIRED) gentoo-dev 2005-09-03 00:10:41 UTC
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.
Comment 1 Jason Stubbs (RETIRED) gentoo-dev 2005-09-04 04:16:50 UTC
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. 
Comment 2 Gregorio Guidi (RETIRED) gentoo-dev 2005-09-20 02:40:33 UTC
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? 
 
Comment 3 Jason Stubbs (RETIRED) gentoo-dev 2005-09-20 06:35:08 UTC
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. 
Comment 4 Carsten Lohrke (RETIRED) gentoo-dev 2005-09-20 07:59:37 UTC
(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.
Comment 5 Jason Stubbs (RETIRED) gentoo-dev 2005-09-20 16:35:03 UTC
So what is the purpose for versioning the user's config? 
Comment 6 Carsten Lohrke (RETIRED) gentoo-dev 2005-09-21 10:25:51 UTC
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.
Comment 7 Michael Gisbers 2005-10-04 07:16:00 UTC
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 ;-) 
Comment 8 Petteri Räty (RETIRED) gentoo-dev 2005-11-29 10:44:46 UTC
So we could make the startkde in 3.5 mv to .kde instead of cp  and then use that
in later releases?
Comment 9 Dan Armak (RETIRED) gentoo-dev 2005-11-29 11:02:08 UTC
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.  
Comment 10 Carsten Lohrke (RETIRED) gentoo-dev 2005-11-29 11:18:38 UTC
(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.
Comment 11 Gregorio Guidi (RETIRED) gentoo-dev 2005-11-29 11:25:36 UTC
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. 
Comment 12 Carsten Lohrke (RETIRED) gentoo-dev 2007-04-25 15:49:12 UTC
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.