Uploads to lenny and the $KDEHOME dilemma

[Alejandro Exojo]

Hi.

First of all, I want to say that I'm mostly a user, but since I follow KDE 
development as much as my time allows, I want to say something from my point 
of view. Sorry if I missed something important, though. :-)

El Martes, 3 de Febrero de 2009, Armin Berres escribió:
> To overcome this, we had the following idea in IRC: Provide a little Qt
> application which starts at the first KDE 4 start and allows the users to
> copy their KDEHOMEs around.
> In case we would use ~/.kde for KDE 4 the script could offer to create a
> backup in ~/.kde3 so lost data can be reverted if anything goes wrong.
> If we continue to use ~/.kde4 the application could offer to copy ~/.kde to
> ~/.kde4.
> Non-KDE users are a bit lost here, we could document what to copy where.
>
> So, which options do you see? What would you prefer?

Say that you decide to keep ".kde4" as default.

Is there a way of migrating the configuration of those who don't use a KDE 4 
desktop? I can't thing of one. If I understood properly, the kres-migrator 
from kdepim was created with this in mind: if a KResources enabled 
application starts (no matter if it's inside a KDE desktop or not), it will 
be triggered. So the only way I can imagine is patching kdelibs. :-(

Say one user has Lenny's akregator installed, and has not only its 
configuration, but has in the akregator storage some stories that considers 
valuable marked as important. When upgrades to Squeeze, if is not using KDE 4 
as desktop, there is no way that Squeeze's akregator finds the feeds in the 
old KDEHOME, isn't it?

Is somehow the situation I am right now: I've selectively upgraded many 
packages to its KDE 4 version, but I've been a bit conservative, and I have 
not touched kdebase or kdepim. I had to spend some time reconfiguring apps or 
manually copying config files, but it wasn't a big deal because there was not 
any important data. My next step will be to upgrade kdepim, but I will not 
notice any improvement with a migration tool, because kdebase will be the 
last package. I will have to migrate manually.

In my humble opinion, this is a big con against this idea. And you still have 
to create a tool that does the copying from one config to the other, which is 
not the upstream way.

But what are the problems of reverting back to ".kde"?

Well, the only users who will have problems with this will be those who 
upgrade to KDE 4, dislike it, want to go back to KDE 3, and find that some 
configuration is not downgradable. I think this problem is not as important 
as the others for the following reasons:

First, I think that the most important data will still be there in the same 
format (KMail will save in maildir or mailbox, KAdressBook and KOrganizer in 
whatever format the resource the user has set, Kopete's logs in XML, etc.). 
Second, the user who wants to go back, will very likely be a user of 
unstable/testing (we don't know how will be the KDE shipped with Squeeze, but 
I doubt it will be so bad), so we can expect that users of this Debian's 
branches are enough proficient to realize that a big KDE upgrade is coming, 
and make a copy of their ~/.kde if they care a lot about that. A warning 
through NEWS.Debian can still be included, of course.

A different issue are programs not properly upgrading their config to KDE 4, 
but this is clearly a bug in the application (not a Debian specific issue), 
and upstream should help to properly use kconfig_update to fix it, because 
it's the mechanism explicitly created to do this.

My 2¢. :)

Greetings.

-- 
Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2
http://barnacity.net/ | http://disperso.net