Darrell,
I ran into a weird problem. I replace R14 with 3513 on a test box. I deleted all /var/tmp/ files and my ~/profile, but forgot to delete /root. When I checked the /root directory, it had /root/.kde, /root/.kde3, /root/.kde4 and /root/.trinity.
After several apps were run kdesu, I noticed many 'tdxxx' directories had been created in /opt/trinity/share/xxx. This was after I had deleted /opt/trinity completely. Could the migration/update scripts cause this?
Do the scripts even handle a R14->3513 install?
Do the scripts even handle a R14->3513 install?
Nope.
At first glance that would be beyond the scope and intent of project goals. Then upon reflection I thought, why?
No good reason. In an ideal world I suppose we should support both directions. I'm sure there will be users who will test R14, say WTF for various unexpected problems and want to revert to 3.5.x.
A temporary fix would be for users to copy both scripts (migratekde3, r14-xdg-update) with new names (restorekde3, r14-xdg-restore?) and then reverse all of the replacement snippets.
Somebody who is a script wizard could revise the existing scripts such that users could use the scripts in either direction.
Darrell
On 08/19/2012 01:06 PM, Darrell Anderson wrote:
Do the scripts even handle a R14->3513 install?
Nope.
On back-burner todo, right behind getting all the darn documents on 3513 to show up in correct spot.
-
Darrell Anderson -
David C. Rankin