Upgrading user configuration after package update

Registered by Didier Roche-Tolomelli


Sometimes, we need to change/update some user configuration on upgrade. However, as everyone knows, the upgrade/installation phase is proceeded by root, so we dont have a sane and secured access to all user data on this machine at this particular time.

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.desktop"], and so if ubuntuone.desktop is renamed after a system upgrade, the launcher will just drop ubuntuone.desktop but not showing the new one. An upgrade to detect that case and replace ubuntuone.desktop with the new name will be handy.
- 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

Sebastien Bacher
Didier Roche-Tolomelli
Didier Roche-Tolomelli
Series goal:
Accepted for quantal
Milestone target:
milestone icon quantal-alpha-3
Started by
Kate Stewart
Completed by
Didier Roche-Tolomelli

Related branches



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://blueprints.launchpad.net/ubuntu/+spec/desktop-q-user-config-change-post-package-upgrade>.

[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_get_mapped() to provide background fallbacks to system defaults: DONE
[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://wiki.ubuntu.com/SoftwareUpdates#After_installing>: DONE
[tedg] Indicator session to prompt for logout when new applicable migration scripts are available: POSTPONED

This blueprint contains Public information 
Everyone can see this information.