Message: previous - next
Month: October 2012

Re: [trinity-devel] Sanity checks to the migratekde3 (commit 58823f36)

From: Slávek Banko <slavek.banko@...>
Date: Sun, 7 Oct 2012 20:33:24 +0200
On Sunday 07 of October 2012 19:33:47 Darrell Anderson wrote:
> > I've combined your patch with my modification. Instead of
> > renaming based on the existence of binaries, I introduced a variable
> >
> > What do you think about it?
> Looks fine to me. Go ahead and push. :)
> I was concerned about using tde-config because of the original bugs
> that created profile directories in the system root or in the user's
> $HOME. Looking at the change log indicates the related patches
> were backported to in kde-config, so I think we're safe.
> If somebody is using 3.5.10 - 3.5.13, the original kde-config will not
> have been patched, but with the migratekde3 patching these config file
> renaming snippets will not execute anyway. Further, previously I added
> a snippet to use konqueror to determine the version rather than
> kde-config for those older Trinity versions.
> I still have my 3.5.10 profiles, which I use to test migratekde3. I
> don't have 3.5.11 -> 3.5.13 profiles. Hopefully before R14 is released
> others with those previous Trinity versions will have tested
> migratekde3.
> We have to be careful to keep migratekde3 and r14-xdg-update unique.
> They serve two different purposes and we don't want overlap. For
> example, my recent patch to support Quanta Plus plugins.rc in
> r14-xdg-update. That involved renaming but the renaming occurred in the
> R14 development.
> Darrell

Pushed in GIT hash ad8633f6.

I understand - in startkde is also instead of kde-config used konqueror. 
Also I understand the reasons to keep a separate script for migration 
from KDE3 and migration XDG.

I have another suggestion for change. During the search in the profile is 
treated, they are not searched folders in kmail/mail. But the same is 
necessary for folders dimap, imap and also autosave. On the folder 
kmail/search I'm not sure. Proposed patch attached.

Next, I wanted to ask whether we can assume the presence of xargs on the 
users machines? It can in the replacement lower overhead of repeated 
execution sed and thus increase the speed. For example:

  find $HOME/.trinity \
       -path $HOME/.trinity/share/apps/kmail/autosave -prune -o \
       -path $HOME/.trinity/share/apps/kmail/dimap -prune -o \
       -path $HOME/.trinity/share/apps/kmail/imap -prune -o \
       -path $HOME/.trinity/share/apps/kmail/mail -prune -o \
       -path $HOME/.trinity/share/apps/kmail/search -prune -o \
       -type f -print0 | \
  xargs -r0 sed -i "s|/opt/kde/|${TDEDIR}/|g"

Instead of launching many sed, how much will be files, can be run only one 
sed, which will process all files that are found.

What is your opinion on this?