Pref Migration Summary

Warren Togami wtogami at
Wed Apr 11 14:21:07 EDT 2007

(Just summarizing what was discussed in #pidgin today.)

.gaimrc (ancient version)
.gaim   (1.5.x)
.pidgin (2.0.0+)

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 
sometimes broken.
- 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 
being consistent.

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.

Symlink Case
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.

Warren Togami
wtogami at

More information about the Devel mailing list