[pkg-kde-talk]Re: Uploads to lenny and the $KDEHOME dilemma

[Raúl Sánchez Siles]

El Miércoles 04 Febrero 2009, Alejandro Exojo escribió:
> 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

  Mostly +1.  Developing an application, mostly Debian specific it's quite 
time, resources and test demanding. Worst of all is that Debian would diverge 
from upstream which as I see it, it's not Team's policy. If we consider 
user's data critical, as worst case[0], there should also be a method to 
rollback the operation. In summary, tricky.

  Focus would also have to be paid into Lenny -> Squeeze migration. If we 
consider Lenny stable and testing(future Squeeze) a moving target, there 
should be some "guaranty" that migration from KDE3 to testing(future Squeeze) 
KDE4.x version will be successful. If that fails, upstream should be 
informed. Additionally, just because the undesirable result(data loss) can 
happen, a backup mechanism should be provided, IMO either telling the user to 
backup ~/.kde or doing it automatically if such migration is detected[1]. I 
think this method will be less painful for the Team and simpler for all in 
general.

[0] I reckon some data/configurations are irrelevant, like icons position on 
desktop. Some other, as e-mail is not.
[1] Raise hand if you don't have a backup of your important data. ;)

-- 
     Raúl Sánchez Siles
----->Proud Debian user<-----
Linux registered user #416098
-------------- 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/75ab31d0/attachment.pgp