Intrepid->Jaunty upgrade wants to clobber /etc/gconf/2/path.debathena

[jdreed]

debathena / upgrade / jdreed 14:36 (Jonathan Reed)

I have a debconf dialog asking me what I want to do about
"path.debathena", because apparently gconf2-common wants to clobber it

debathena / upgrade / andersk 14:38 (Anders Kaseorg)

Oh, /etc/gconf/2/path is ucf-managed. Huh.

debathena / upgrade / andersk 14:38 (Anders Kaseorg)

Things should work if you let it clobber the file.

[jdreed]

As it turns out, if you let gconf2-common clobber the file, then when it comes time to install debathena-gconf2-config, it detects that /etc/gconf/2/path.debathena has been modified and again prompts the user to overwrite it.

[jdreed]

Is this fixable? It will likely show up in the Jaunty->Karmic upgrade I'm told. If it's fixable, we should fix it. If not, we should document it and move on.

[jdreed]

If it's "fixable" by moving it out of the way before the upgrade and then moving it back, so as to avoid do-release-upgrade complaining, then perhaps we should provide some sort of debathena-update_ws script which prepares the system for do-release-upgrade and then cleans up at the end

[jdreed]

Documented.  http://kb.mit.edu/confluence/x/0wxa

Re-milestoning.

[broder]

I think something more sinister may be going on here.

When I upgraded opus to Lucid, I got the prompt about overwriting /etc/gconf/2/path.debathena. After the upgrade finished, /etc/gconf/2/path.debathena had been reverted to the upstream gconf2 path file (and not /etc/gconf/2/path), meaning that gconf was being run with ~/.gconf as its source instead of ~/.gconf-debathena-lucid.

[broder]

I'm bumping the priority on this one, because I think we need to get a better understanding of what's going on before a bunch of people start upgrading their workstations.

[broder]

Here's a thought:

Instead of diverting /etc/gconf/2/path, what if we diverted /usr/share/gconf/default.path, and then ran ucf /usr/share/gconf/default.path /etc/gconf/2/path ourselves? ucf would think that our version of /usr/share/gconf/default.path was the "upstream template", having been changed from the one that gconf2-common actually provides, and would silently replace the upstream /etc/gconf/2/path with our own.

I haven't exactly figured out what the right upgrade path is for machines that already have gconf2-config installed, though. Still working on that.

[broder]

(This should work because /usr/share/gconf/default.path is installed as part of the gconf2-common package, meaning that in the case of a gconf2-common upgrade, our diversions would be respected, and ucf wouldn't notice any changes in /usr/share/gconf/default.path)

[broder]

I think I've figured out how to execute this transition in a maximally Correct way.

First of all, there's the simple case. In the simple case, the user hasn't intentionally modified the gconf configuration after installing our package.

If that's the case, all we have to do is run ucf --purge /etc/gconf/2/path, divert /usr/share/gconf/default.path, then run ucf /usr/share/gconf/default.path /etc/gconf/2/path to re-sync everything back up.

Because of ucf's symlink handling (which means that users may have blindly overwritten our version of /etc/gconf/2/path with the upstream default version), I'm willing to assume that the user hasn't intentionally modified our gconf configuration if

1. /etc/gconf/2/path still points to path.debathena (as opposed to path.debathena-orig)
2. /etc/gconf/2/path.debathena matches any version of /etc/gconf/2/path shipped by either gconf2-common or debathena-gconf2-config

If one of these two conditions doesn't hold, then we know that the user made a conscious effort to change the configuration. In both cases, we shouldn't run ucf --purge, because that will destroy information about the file conflict.

If the first condition is false, that's good enough. Undoing the diversion won't change the contents of the file pointed to by /etc/gconf/2/path, so the next ucf run will put our configuration against the user's configuration.

If the first condition is true but the second condition is false, then we also need to replace /etc/gconf/2/path (which was previously /etc/gconf/2/path.debathena-orig) with /etc/gconf/2/path.debathena. Because the user has made changes to /etc/gconf/2/path.debathena, again this means that the next ucf run will put our configuration against the user's configuration. Scribbling over /etc/gconf/2/path isn't a problem here, because we assume the user modified path.debathena in lieu of modifying path.debathena-orig (now path)

[broder]

Just as a note for myself, when this gets uploaded, here are the scenarios that should be tested:

1. ucf --purge doesn't get run if the package wasn't previously installed
2. No ucf conflict is presented if
   1. debathena-gconf2-config 1.6 is installed then upgraded to 1.7
   2. debathena-gconf2-config 1.6 is installed, the workstation's Ubuntu release is upgraded, ucf scribbles over /etc/gconf/2/path.debathena, then gconf2-config is upgraded to 1.7
   3. debathena-gconf2-config 1.6 is installed, workstation is upgraded, ucf scribbles over path.debathena, then debathena-gconf2-config scribbles over path.debathena, then gconf2-config is upgraded to 1.7

3. A ucf conflict is presented if /etc/gconf/2/path points to path.debathena-orig on upgrade (NOTE: this doesn't work with my current code)
4. A ucf conflict is presented if /etc/gconf/2/path.debathena is edited by hand

[broder]

Fixed in r24493.

Because a lot of the testing for this change revolves around upgrade behavior, I opted to put the package in development for the time being. This will make it a little easier to test various upgrade paths from machines that already update from proposed.

Once we've done some testing on the assorted upgrade paths, I'll move the package into proposed.

[broder]

Ok. I've now tested all of the scenarios I outlined in comment:11, so I've rebuilt the package and uploaded it to proposed.

[broder]

Moved to production today.