After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 340640 - evolution does not store its configuration data in one location
evolution does not store its configuration data in one location
Status: RESOLVED DUPLICATE of bug 300940
Product: evolution
Classification: Applications
Component: general
2.6.x (obsolete)
Other All
: Normal minor
: ---
Assigned To: Harish Krishnaswamy
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2006-05-04 15:05 UTC by Dave Allan
Modified: 2006-05-10 17:49 UTC
See Also:
GNOME target: ---
GNOME version: 2.11/2.12



Description Dave Allan 2006-05-04 15:05:05 UTC
Evolution stores its configuration in at least three places, ~/.evolution
~/.gconf/apps/evolution and ~/.gnome2_private/Evolution  As a result, there's no
single directory that can be backed up and restored to get a functioning
application.  

.gconf has occasionally been known to become corrupt, and users must then sort
out which bits of that directory tree are still good and which are not.  In my
case, fixing a problem with the gnome desktop itself, because I wasn't careful,
trashed my evolution configuration.  I removed my .gconf directory so I could
login, forgetting that evolution stored its data there.  Fortunately, I had a
backup.  

I don't want to sound religious about this, and I understand the value of a
registry for presenting an integrated desktop environment, but I think evolution
and Gnome generally are falling into the registry trap that made Windows so
difficult to recover from faults.  I don't want to see Gnome become an
environment where, "Reinstall the box" is the only solution.  

There has to be a way to get the benefits of a registry while preserving the
*nix mantra of "one directory per application".  

Other information:
Comment 1 André Klapper 2006-05-10 16:32:14 UTC
could be a duplicate of bug 300940.
Comment 2 Dave Allan 2006-05-10 17:49:47 UTC
I'm resolving this bug as a dup, particularly as http://go-evolution.org/Evo2.6#Unified_Account_Management suggests that the development team feels the same way I do about this issue.  

*** This bug has been marked as a duplicate of 300940 ***