Darrell,
I looked at the commit 58823f36, and I propose to adjust sanity checks so that instead of binaries existence check the existence of configuration file.
For example: I had previously installed Krita => I have configuration. But at this moment I have not installed Chalk => configuration is not converted. When I install Chalk later, the configuration will be missing.
In addition, testing tdeprint based on the /opt/trinity/include/tdeprint is not appropriate. I have installed package tdeprint-trinity, but /opt/trinity/include/tdeprint not exists. This is a part of package tdelibs-trinity-dev.
Slavek --
I looked at the commit 58823f36, and I propose to adjust sanity checks so that instead of binaries existence check the existence of configuration file.
For example: I had previously installed Krita => I have configuration. But at this moment I have not installed Chalk => configuration is not converted. When I install Chalk later, the configuration will be missing.
In addition, testing tdeprint based on the /opt/trinity/include/tdeprint is not appropriate. I have installed package tdeprint-trinity,
but /opt/trinity/include/tdeprint not exists. This is a part of package tdelibs-trinity-dev.
How about this:
diff -urN tdebase/migratekde3 tdebase.new/migratekde3 --- tdebase/migratekde3 2012-09-29 01:35:28.000000000 -0500 +++ tdebase.new/migratekde3 2012-10-06 22:38:01.000000000 -0500 @@ -320,32 +320,32 @@ fi echo "Renaming various configuration files and directories." # Don't force renaming in case this cript is used to update an existing Trinity profile. - if [ -f $TDEDIR/bin/chalk ]; then + if [ -f $HOME/.trinity/share/config/kritarc ] || [ -d $HOME/.trinity/share/apps/krita ]; then echo " krita->chalk" mv $HOME/.trinity/share/config/kritarc $HOME/.trinity/share/config/chalkrc 2>/dev/null mv $HOME/.trinity/share/apps/krita $HOME/.trinity/share/apps/chalk 2>/dev/null fi - if [ -d /opt/trinity/include/tdeprint ]; then + if [ -f $HOME/.trinity/share/config/kdeprintrc ] || [ -d $HOME/.trinity/share/apps/kdeprint ]; then echo " kdeprint->tdeprint" mv $HOME/.trinity/share/config/kdeprintrc $HOME/.trinity/share/config/tdeprintrc 2>/dev/null mv $HOME/.trinity/share/apps/kdeprint $HOME/.trinity/share/apps/tdeprint 2>/dev/null fi - if [ -f $TDEDIR/bin/tdesu ]; then + if [ -f $HOME/.trinity/share/config/kdesurc ]; then echo " kdesurc->tdesurc" mv $HOME/.trinity/share/config/kdesurc $HOME/.trinity/share/config/tdesurc 2>/dev/null fi - if [ -f $TDEDIR/bin/tdevelop ]; then + if [ -f $HOME/.trinity/share/config/kdeveloprc ]; then echo " kdevelop->tdevelop" mv $HOME/.trinity/share/config/kdeveloprc $HOME/.trinity/share/config/tdeveloprc 2>/dev/null fi - if [ -f $TDEDIR/bin/twin ]; then + if [ -f $HOME/.trinity/share/config/kwinrc ] || [ -d $HOME/.trinity/share/apps/kwinrulesrc ]; then echo " kwin->twin" mv $HOME/.trinity/share/config/kwinrc $HOME/.trinity/share/config/twinrc 2>/dev/null mv $HOME/.trinity/share/config/kwinrc.eventsrc $HOME/.trinity/share/config/twinrc.eventsrc 2>/dev/null mv $HOME/.trinity/share/config/kwinrc $HOME/.trinity/share/config/twinrc 2>/dev/null mv $HOME/.trinity/share/apps/kwinrulesrc $HOME/.trinity/share/apps/twinrulesrc 2>/dev/null fi - if [ -f $TDEDIR/bin/twin4 ]; then + if [ -f $HOME/.trinity/share/config/kwin4rc ]; then echo " kwin4->twin4" mv $HOME/.trinity/share/config/kwin4rc $HOME/.trinity/share/config/twin4rc 2>/dev/null fi
Darrell
How about this:
That patch will not help.
Whereas krita was renamed to chalk before 3.5.13 was released, the others were not renamed until after 3.5.13. Thus, renaming those respective config files for 3.5.13 or 3.5.13.1 users will make things worse. After I posted the patch I remembered that is why why I tested the existence of the executables.
The patch for krita/chalk probably is safe. For tdeprint, rather than test for the include file because Debian separates user and developer files, the next best test probably is [ -d $TDEDIR/share/apps/tdeprint].
Darrell
That patch will not help.
Whereas krita was renamed to chalk before 3.5.13 was released, the others were not renamed until after 3.5.13. Thus, renaming those respective config files for 3.5.13 or 3.5.13.1 users will make things worse. After I posted the patch I remembered that is why why I tested the existence of the executables.
The patch for krita/chalk probably is safe. For tdeprint, rather than test for the include file because Debian separates user and developer files, the next best test probably is [ -d $TDEDIR/share/apps/tdeprint].
How about this:
diff -urN tdebase/migratekde3 tdebase.new/migratekde3 --- tdebase/migratekde3 2012-09-29 01:35:28.000000000 -0500 +++ tdebase.new/migratekde3 2012-10-06 23:01:41.000000000 -0500 @@ -320,32 +320,32 @@ fi echo "Renaming various configuration files and directories." # Don't force renaming in case this cript is used to update an existing Trinity profile. - if [ -f $TDEDIR/bin/chalk ]; then + if [ -f $HOME/.trinity/share/config/kritarc ] || [ -d $HOME/.trinity/share/apps/krita ]; then echo " krita->chalk" mv $HOME/.trinity/share/config/kritarc $HOME/.trinity/share/config/chalkrc 2>/dev/null mv $HOME/.trinity/share/apps/krita $HOME/.trinity/share/apps/chalk 2>/dev/null fi - if [ -d /opt/trinity/include/tdeprint ]; then + if [ -d $TDEDIR/share/apps/tdeprint ] && [ -f $HOME/.trinity/share/config/kdeprintrc ] || [ -d $HOME/.trinity/share/apps/kdeprint ]; then echo " kdeprint->tdeprint" mv $HOME/.trinity/share/config/kdeprintrc $HOME/.trinity/share/config/tdeprintrc 2>/dev/null mv $HOME/.trinity/share/apps/kdeprint $HOME/.trinity/share/apps/tdeprint 2>/dev/null fi - if [ -f $TDEDIR/bin/tdesu ]; then + if [ -f $TDEDIR/bin/tdesu ] && [ -f $HOME/.trinity/share/config/kdesurc ]; then echo " kdesurc->tdesurc" mv $HOME/.trinity/share/config/kdesurc $HOME/.trinity/share/config/tdesurc 2>/dev/null fi - if [ -f $TDEDIR/bin/tdevelop ]; then + if [ -f $TDEDIR/bin/tdevelop ] && [ -f $HOME/.trinity/share/config/kdeveloprc ]; then echo " kdevelop->tdevelop" mv $HOME/.trinity/share/config/kdeveloprc $HOME/.trinity/share/config/tdeveloprc 2>/dev/null fi - if [ -f $TDEDIR/bin/twin ]; then + if [ -f $TDEDIR/bin/twin ] && [ -f $HOME/.trinity/share/config/kwinrc ] || [ -d $HOME/.trinity/share/apps/kwinrulesrc ]; then echo " kwin->twin" mv $HOME/.trinity/share/config/kwinrc $HOME/.trinity/share/config/twinrc 2>/dev/null mv $HOME/.trinity/share/config/kwinrc.eventsrc $HOME/.trinity/share/config/twinrc.eventsrc 2>/dev/null mv $HOME/.trinity/share/config/kwinrc $HOME/.trinity/share/config/twinrc 2>/dev/null mv $HOME/.trinity/share/apps/kwinrulesrc $HOME/.trinity/share/apps/twinrulesrc 2>/dev/null fi - if [ -f $TDEDIR/bin/twin4 ]; then + if [ -f $TDEDIR/bin/twin4 ] && [ -f $HOME/.trinity/share/config/kwin4rc ]; then echo " kwin4->twin4" mv $HOME/.trinity/share/config/kwin4rc $HOME/.trinity/share/config/twin4rc 2>/dev/null fi
Darrell
On Sunday 07 of October 2012 06:04:04 Darrell Anderson wrote:
That patch will not help.
Whereas krita was renamed to chalk before 3.5.13 was released, the others were not renamed until after 3.5.13. Thus, renaming those respective config files for 3.5.13 or 3.5.13.1 users will make things worse. After I posted the patch I remembered that is why why I tested the existence of the executables.
The patch for krita/chalk probably is safe. For tdeprint, rather than test for the include file because Debian separates user and developer files, the next best test probably is [ -d $TDEDIR/share/apps/tdeprint].
I've combined your patch with my modification. Instead of renaming based on the existence of binaries, I introduced a variable TDE_REBRAND.
What do you think about it?
Slavek --
I've combined your patch with my modification. Instead of renaming based on the existence of binaries, I introduced a variable TDE_REBRAND.
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 3.5.13.1 change log indicates the related patches were backported to 3.5.13.1 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
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 TDE_REBRAND.
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 3.5.13.1 change log indicates the related patches were backported to 3.5.13.1 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?
Slavek --
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.
I have no problem with excluding imap folders but I can't test because I don't use imap.
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?
If xargs on all systems is a safe presumption then I have no problem with that either. I should make more use of xargs in my own habits. Just lazy. :)
If your testing of the imap and xarg changes work on your system, I say go ahead and push the patch. I can test the xargs part here.
Darrell
On Sunday 07 of October 2012 22:01:20 Darrell Anderson wrote:
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.
I have no problem with excluding imap folders but I can't test because I don't use imap.
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?
If xargs on all systems is a safe presumption then I have no problem with that either. I should make more use of xargs in my own habits. Just lazy. :)
If your testing of the imap and xarg changes work on your system, I say go ahead and push the patch. I can test the xargs part here.
Darrell
Apart from KMail imap folders I added several other folders that contain user data - see commit in GIT hash f88add0a.
Change to use xargs I will send soon as a separate commit.
Slavek --
On 7 Oct 2012, Darrell Anderson said:
If xargs on all systems is a safe presumption
To a first approximation, nothing will work without xargs: it's in POSIX and GNU coreutils. If distributors are leaving out core parts of a working Unix system I don't think Trinity can be expected to run on them.
(Any non-embedded distributor will be utterly certain to include it. Heck, Android has a copy.)
-
Darrell Anderson -
Nix -
Slávek Banko