Uploads to lenny and the $KDEHOME dilemma

[Sune Vuorela]

On Tuesday 03 February 2009 22:53:42 Armin Berres wrote:
> Hi all!
>
> As you all know Lenny is near, which also means that our 4.2 packages will
> enter Unstable in the very near future. Until today, we still have not
> decided how to handle KDEHOME.
> The current situation is, that KDE 3 applications use ~/.kde and KDE 4
> applications use ~/.kde4. The problem with this approach is, that no
> data/settings are automatically converted to be used by KDE 4.
>
> The question is now: should we
> a) continue to use ~/.kde4 for KDE 4 applications
> b) use ~/.kde for KDE 4 applications.
>
> The problem with a) is, that as mentioned no data is is moved to KDE 4. The
> problem with b) is, that we don't know for sure, if all upgrade scripts
> work and users don't loose critical data. Apart from that users already
> using KDE 4 won't find their settings copied.
> (Add here more pros and cons for either option.)
>
> 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?
> Don't forget that we have to decide/code all this before we upload kde4libs
> to unstable.

After thinking even further, I really think that going .kde is the only way. 
If not, people will lose their contacts in kopete
People will lose their contacts in kaddressbook
People will lose their book database in tellico when tellico goes kde4
people will lose emails stored locally
people will lose the content of their kwallet.
and so on.  (really powerusers understanding where and how kconf_update might 
do and not do things might be able to recover things, but not any ordinary 
user - and I might have issues as well)

The only way to avoid users losing data  and sticking to .kde4 is by making 
kdelibs in kde4 (not in startkde or anywhere else) migrate data on application 
startup. To be honest, I'm quite sure we don't have the skills in kde team to 
actually do these changes to kdelibs)

Who are we screwing by keeping using .kde for kde4 data?
 - users who might want to migrate back. 
 - current users of kde4 in experimental.

The first group of the users we are screwing should just do a cp .kde kde3 if 
they are unsure.
The second group of users managed to migrate from .kde to .kde4. They should 
be able to migrate back as well.

But by screwing those two groups of users, we are actually unscrewing all the 
other users of the kde desktop *and* the kde applications.
And we just heard; in ubuntu they had no problems with this large scale 
migration of things.


So, currently I think the only right decision is .kde.

/Sune
-- 
Man, how can I debug a LCD BIOS periferic of the CPU to the hard disk on the 
modem from Office 7.4?

You either should never save a ROM e-mail, or can never doubleclick a sendmail 
for booting a TCP display.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://lists.alioth.debian.org/pipermail/pkg-kde-talk/attachments/20090204/75e7a66d/attachment.pgp