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
- 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
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
ubuntu-desktop mailing list