Bug#456114: gconf: Please support splitting preferences into multiple files by path

2008-01-11 Thread Josselin Mouette
Hi,

Le mercredi 12 décembre 2007 à 23:49 -0800, Josh Triplett a écrit :
 I keep my home directory in version control, as a means of sharing it
 across systems, keeping it backed up, and tracking changes to it.  I'd
 like to add some of my gconf configuration to version control as well.
 However, gconf contains various types of preferences, some of which I
 want to version and some of which I do not.  For instance, I would
 like to version /apps/metacity/general/num_workspaces,
 /apps/evolution/mail/display/thread_list, and most of
 /apps/gnome-terminal, but I do not want to version
 /apps/evolution/last_version,
 /apps/gnome-settings/gnome-panel/history-gnome-run, or
 /apps/meld/window_size_{x,y}.
 
 Thus, I'd like the ability to have multiple readwrite gconf stores,
 with different (non-overlapping) sets of preferences stored in each.
 I could then have all the prefs I want to version stored in one file,
 machine-specific prefs stored in another file (bonus if I can use the
 hostname in the filename, so all the machine-specific files can
 coexist in parallel), all the prefs I never want to version in a file
 to ignore, and all other prefs in a new file so I can check and
 classify them.
 
 This potentially shares some goals with online-prefs-sync, which would
 also benefit from having a list of preferences safe to sync across
 machines, and which provides some support for the idea of safely
 changing a store underneath gconf and having it notice.  However, it
 differs in several ways, most notably the use of local stores for
 everything.

This is definitely a good idea, but it far outreaches what we can afford
to do in Debian. You should bring this up on the upstream list
(gconf-list at gnome dot org).

Just like online-prefs-sync, this is also probably something that would
be more easily implemented as a separate application. Just define a list
of directories and dump them in a versioned directory, and you just have
to write some code to go back and forth. Symbolic links in the gconf
tree might also work.

Cheers,
-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée


Bug#456114: gconf: Please support splitting preferences into multiple files by path

2007-12-12 Thread Josh Triplett
Package: gconf
Severity: wishlist

I keep my home directory in version control, as a means of sharing it
across systems, keeping it backed up, and tracking changes to it.  I'd
like to add some of my gconf configuration to version control as well.
However, gconf contains various types of preferences, some of which I
want to version and some of which I do not.  For instance, I would
like to version /apps/metacity/general/num_workspaces,
/apps/evolution/mail/display/thread_list, and most of
/apps/gnome-terminal, but I do not want to version
/apps/evolution/last_version,
/apps/gnome-settings/gnome-panel/history-gnome-run, or
/apps/meld/window_size_{x,y}.

Thus, I'd like the ability to have multiple readwrite gconf stores,
with different (non-overlapping) sets of preferences stored in each.
I could then have all the prefs I want to version stored in one file,
machine-specific prefs stored in another file (bonus if I can use the
hostname in the filename, so all the machine-specific files can
coexist in parallel), all the prefs I never want to version in a file
to ignore, and all other prefs in a new file so I can check and
classify them.

This potentially shares some goals with online-prefs-sync, which would
also benefit from having a list of preferences safe to sync across
machines, and which provides some support for the idea of safely
changing a store underneath gconf and having it notice.  However, it
differs in several ways, most notably the use of local stores for
everything.

- Josh Triplett

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.24-rc4 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]