Pref Migration Summary
wtogami at redhat.com
Wed Apr 11 14:21:07 EDT 2007
(Just summarizing what was discussed in #pidgin today.)
.gaimrc (ancient version)
Shared Homedir Case
This is a relatively rare case, but problematic for those users if
gaim-1.5.x and pidgin-2.0.0+ insists on keeping a shared prefs
directory. Problems include:
- 1.5.x confused by prefs written by 2.0.0+. Behavior is odd and
- Prefs written by 1.5.x break some prefs written by 2.0.0+, requiring
you to reconfigure when you run 2.0.0 again. This is the flip-flopping
- 2.0.0 might be able to be modified in an attempt to avoid
flip-flopping with 1.5.x's pref handling. However, if this remains a
requirement, then pidgin is probably hindered in future progress.
It is broken and unsustainable to attempt to share preferences between
1.5.x and 2.0.0 and avoid changes that would break the former. The
prefs between these versions should be made independent. Doing so, we
avoid problems for users with strange/broken client behavior and
flip-flopping of preferences.
Use .gaim Forever?
Luke (and others) indicated that if we don't make a change away from
.gaim now, we will be stuck with it for a while.
pidgin-2.0.0 one-time migration
If .gaim exists DO NOT MODIFY IT. Instead migrate it to .pidgin. .gaim
is left untouched, so if 1.5.x runs, it isn't confused by prefs written
by newer versions. Furthermore, prefs are not flip-flopping if you
again run 2.0.0 after 1.5.x.
A one-time migration would be a SIMPLE and working solution that avoids
limitations for future development.
Shared Logging Handling: OPTIONAL?
It was discussed that Pidgin could intelligently handle logs in either
location. Somehow. Implementation details were vague.
IMHO, this really isn't important to do at all. It is simpler and the
right thing to just keep the logs separate after the one-time migration.
Why? The shared user homedir case is rare. Those users are more
concerned with the client working (avoid pref flip-flopping) than logs
Furthermore, if you try to maintain shared logs, then this creates
complications if the log format wants to change again in the future.
Now, if somebody can think of a sane way to implement this, keeping in
mind that 1.5.x's log handling behavior wont change, then go ahead. I'm
doubtful that this important at all.
Stu was concerned about the extreme minor of power users or devs that
have symlinks within their gaim/pidgin prefs. Given that this is not a
The code could detect symlinks and handle it appropriately. What is the
appropriate way to handle it? This isn't clear.
Given how rare and non-standard this is, it is probably best to keep the
code simple and ignore it. Users who did this to themselves are smart
enough to fix it on their own.
wtogami at redhat.com
More information about the Devel