User configuration change after package upgrade

Registered by Jason Warner on 2012-04-25

I know that will sound like a deja-vu for some of you (we did discuss about it at UDS Brussels IIRC), however I think the situation nowdays will make it more needed than what it was in the past.

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.

So, I want to open the discussion on how to do this in a light and harmless way (no python for instance ;)). Stamp that a migration happened. Should this be some triggered by client packages themselves? When should this be run in the session? and so on :)

Blueprint information

Didier Roche
Needs approval
Didier Roche
Series goal:
Milestone target:
Completed by
Didier Roche on 2012-05-14

Related branches



[mpt] This is a duplicate of <>.

[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.


Work Items

This blueprint contains Public information 
Everyone can see this information.