Upgrading user configuration after package update
Rationale:
Sometimes, we need to change/update some user configuration on upgrade. However, as everyone knows, the upgrade/
Of course, there is still the gold rule "don't change user configuration on upgrade" that we try to keep as much as possible, and in this case, changing the gsettings default is just enough most of the time. However, some cases are still valid and changing the gsettings default doesn't work, on top of my head:
- Unity launcher icons. Some softwares renames their .desktop file name (ubuntu one for instance) in newer release. The key for those icons are put together in a list ["firefox.desktop", "ubuntuone.
- We got the glorious example on compiz in the past. Fortunatly, this one will soonly be fixed with the case of gsettings, but we surely do have other similar cases when a default is reset to the default and not considered as such.
- Even if compiz is fixed, we needed to change the default plugin list more than once, depending on which profile is running, that's another use case.
Blueprint information
- Status:
- Complete
- Approver:
- Sebastien Bacher
- Priority:
- Medium
- Drafter:
- Didier Roche-Tolomelli
- Direction:
- Approved
- Assignee:
- Didier Roche-Tolomelli
- Definition:
- Approved
- Series goal:
- Accepted for quantal
- Implementation:
-
Implemented
- Milestone target:
-
quantal-alpha-3
- Started by
- Kate Stewart
- Completed by
- Didier Roche-Tolomelli
Whiteboard
Test Plans:
1) Unit test for the script itself, handling upgrade on demand
2) Integration tests runned as part of the distro upgrade testing from precise to quantal.
--------- discussion from UDS:
[mpt] This is a duplicate of <https:/
[mpt] Straw-man proposal: Any application should (a) record, for every setting saved in user config, which version saved it, and (b) reset an old setting at runtime if there's a really good reason. For example, if someone set a custom window size for version 1 of an application, the application might obey that setting in versions 2 through 4 -- but then deliberately reset it to a new default in version 5, because the window layout has changed and a size suitable for the old layout isn't suitable for the new one.
Example of user migration needed:
* Unity launcher configuration (desktop files names changes), list of different apps on the launcher
* compiz plugins list
* migrating from a dconf path to another
Proposed solutions from the discussion:
- having gsettings list not writing a list by default if you didn't touch anything
- some kind of give up and start over if the upgrade didn't succeed?
- segragating values between different desktop?
- only focusing on gsettings this cycle, revisit next cycle if we need to deal with other cases
- migration shouldn't delete old files. Better to keep them on disk (forever).
- the "do nothing" has to be fast
- checking path (like a TryExec key) for the currently login user? (and then ask to restart the session if needed?)
- Key file should include user readable to describe what it's doing (translated -- need gettext domain)
- envision how to deal with specific user config not supported (skipping them if detected), like if ccsm was running…
Cancelled work items:
[mpt] define an interface for backing out a configuration and restarting fresh: couldn't be explained in an understandable way
Work Items
Work items for quantal-alpha-2:
[didrocks] dconf blame on the file system to see which programs are writing to the disk: DONE
[didrocks] daily blame from QA for ensuring nothing is writing on first login: DONE
Work items for quantal-alpha-3:
[didrocks] work with desrt on defining a file format for the settings migration and ordering: DONE
[desrt] gsettings list implementation: POSTPONED
[didrocks] create integration tests for the migration tool: DONE
[didrocks] steal the gconf -> gsettings migration (timestamp check) for running migration on every login: DONE
[didrocks] Put all this in a nice, small service at startup and add debhelper hooks: DONE
[seb128] look at making nautilus (gnomebg) use g_gsettings_
[didrocks] migrating dconf keys /apps/unity keys to com.canonical: DONE
[mpt] Design to decide what should be presented to user on logout (red too much?) <https:/
[tedg] Indicator session to prompt for logout when new applicable migration scripts are available: POSTPONED
