In order to make it easy for the user to migrate from a KDE 3 desktop to a KDE 4 desktop, without messing with the configurations, it is necessary to create a Migration Wizard which takes care of this.
Execution
The probably best solution to ensure that the wizard is always executed, is to have a kubuntu-startkde wrapper script which first checks whether migration is necessary at all1, to start the wizard as needed and as soon as it finished, to actually execute the startkde script.
Migration
There are 3 scenarios:
KDE 3 Pre-Hardy (.kde) -> KDE 3 Hardy (.kde3)
KDE 3 Pre-Hardy (.kde) -> KDE 4 (.kde)
KDE 3 Hardy (.kde3) -> KDE 4 (.kde)
Type Detection
In order to properly check which scenario applies, we need to have some special configuration file or a configuration value in an important config (e.g. share/config/kdeglobals). This can represent all 3 states:
file/value not present == KDE 3 Pre-Hardy -> KDE 3 Hardy OR KDE 3 Pre-Hardy -> KDE 4
- In this case we need to check whether KDE 3 or KDE 4 is to be started
file/value contains an indication that we only migrated to KDE 3 yet (means KDE 3 Pre-Hardy -> KDE 3 Hardy) and that the user didn't yet decide what to do with the configurations in KDE 4
- In this case we need to open the actual wizard and ask the user what he wants to do with the .kde3 content
file/value contains an indication that we migrated to KDE 4 == KDE 3 Pre-Hardy -> KDE 4 OR KDE 3 Hardy -> KDE 4
This is the best case scenario, because a KDE 3 Pre-Hardy -> KDE 4 migration also means, that .kde3 has already been created, so if this state is detected, we can just fast forward to startkde
Type State 1 (-> S1, S2)
If type detection returned state 1, the wizard has to find out whether KDE 3 or KDE 4 is to be started, this can either be done by different wrapper scripts, or by passing a special argument to the wrapper script (after all the wrapper script also needs to know which desktop to start, to invoke it's startkde script later on). Depending on the result of this check we either kick off a S12 for KDE 3 or S2 for a KDE 4 migration.
Type State 2 (-> S3)
If type detection returned state 2 migration, the wizard first has to check whether we are actually starting KDE 4:
if not -> startkde
if we do -> just kick off a S3 migration.
Type State 3 (startkde)
If type detection returned state 3 we don't have to do anything since .kde3 migration is done and .kde i used for kde4 already -> startkde.
Scenario 1 Migration
The wizard just moves .kde over to .kde3 and writes a file/value which leads to a state 2 detection.
Scenario 2 Migration
The wizard copies all files from .kde to .kde3
Scenario 3 Migration
The wizard copies all updated files from .kde3 to .kde
Start KDE
As soon as the wizard finished successfully, the wrapper script just executes the startkde script.
Re-Import Configuration (post-migration updates)
Another important feature would be to re-import configurations from KDE 3.
Use Case
Amarok isn't yet available for KDE 4, so one has to use the KDE 3 version. Once the KDE 4 version is out, one might want to import the most current configuration data from KDE 3.
A proposed solution by Riddell is to do this in the postinst script for every KDE 4 package, there is however one issue: some configuration data are fairly big (amarok, kmail) which leads to a very long dpkg lock and high disc usage, same applies to systems with a lot of users. Maybe an own configuration would be reasonable, so users can deactivate all postinst KDE 3 -> KDE 4 configuration updates if they want to.
Notes
For this to work properly we need reliable definition sets (i.e. someone has to find out where Amarok stores which data and write a definition file or something similar) as well as create a script to include in all KDE 4 packages' postinst or place the script seperately, to copy $config from .kde3 if it is newer than the one in .kde.
Misc Notes
- In general it's probably to create a backup of the original .kde folder and place it as a tar.bz2 on the user's desktop (this possibly can be optional for S2 and S3)
- All migration tasks should be done before KDE actually starts (i.e. before startkde gets called), to prevent the happening of really evil things
