Please test the experimental gconf2

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Please test the experimental gconf2

Josselin Mouette
I have just uploaded gconf2 2.12.1-1 to experimental. The package
includes major changes, and therefore needs to be tested before going to
unstable.

First, I hereby proclaim the end of the overly long gconf subtrees.
Following these suggestions:
http://www.gnome.org/~lcolitti/gnome-startup/analysis/
I have merged all gconf directory structures into flat-file sources.
This means startup and runtime speed is improved, and it also means less
cluttering on the disk. There is now only one file, named
%gconf-tree.xml, for each directory structure. The system-wide
directories are taken care in the postinst, and I have added a Xsession
script for ~/.gconf.

Second, there's a (long-awaited) framework for easily setting defaults
without patching the schema files. You can now drop files
in /usr/share/gconf/defaults, with filenames starting with numbers, e.g.
20gnome-session. The number indicates the priority, greater numbers
meaning you can overwrite defaults set in lower priorities. The format
is very simple: each line consists in a key and a value, the type being
autodetected. Running update-gconf-defaults results in making these
defaults available even to running gconfd instances. Currently, the
script is written in python, but if someone rewrites it in
comprehensible perl, the dependency can be dropped. Of course, I will
add support for it to dh_gconf to make it even easier.

Now, GO AHEAD AND TEST IT. Then, WORLD DOMINATION.

Good night,
--
 .''`.           Josselin Mouette        /\./\
: :' :           [hidden email]
`. `'                        [hidden email]
  `-  Debian GNU/Linux -- The power of freedom

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Please test the experimental gconf2

Jean-Christophe Dubacq

Le 14 nov. 05 à 00:35, Josselin Mouette a écrit :

> Second, there's a (long-awaited) framework for easily setting defaults
> without patching the schema files. You can now drop files
> in /usr/share/gconf/defaults, with filenames starting with numbers,  
> e.g.
> 20gnome-session. The number indicates the priority, greater numbers
> meaning you can overwrite defaults set in lower priorities. The format
> is very simple: each line consists in a key and a value, the type  
> being
> autodetected. Running update-gconf-defaults results in making these
> defaults available even to running gconfd instances. Currently, the
> script is written in python, but if someone rewrites it in
> comprehensible perl, the dependency can be dropped. Of course, I will
> add support for it to dh_gconf to make it even easier.

Hi Joss,

It would be marvelous (and probably more FHS compliant) if those  
files were not to be dropped in /usr/share/gconf/defaults, but in /
etc/gconf/defaults.
Or better (I do not know how you perceive the whole thing) if your  
update-gconf-defaults script could read both in /usr/share/gconf/
defaults and /etc/gconf/defaults. The /etc/gconf/defaults would be  
empty and filled only with localadmin-written stuff (btw, this name  
just came as the first off the top of my mind, but could be changed  
to /etc/gconf/local-defaults if this helps with transition from older  
setups).
My centralised setup system takes care of everything under /etc, but  
not things under /usr (this is the holy kingdom of the packages).
--
JCD


Reply | Threaded
Open this post in threaded view
|

Re: Please test the experimental gconf2

Josselin Mouette
Le lundi 14 novembre 2005 à 09:28 +0100, Jean-Christophe Dubacq a
écrit :

> It would be marvelous (and probably more FHS compliant) if those  
> files were not to be dropped in /usr/share/gconf/defaults, but in /
> etc/gconf/defaults.
> Or better (I do not know how you perceive the whole thing) if your  
> update-gconf-defaults script could read both in /usr/share/gconf/
> defaults and /etc/gconf/defaults. The /etc/gconf/defaults would be  
> empty and filled only with localadmin-written stuff (btw, this name  
> just came as the first off the top of my mind, but could be changed  
> to /etc/gconf/local-defaults if this helps with transition from older  
> setups).

All of this is easy to achieve, but the reasoning behind
choosing /usr/share/gconf/defaults was to provide a framework for
packages, not for system administrators. The recommended way to set
local defaults is still to use gconftool or gconf-editor to set them
in /etc/gconf/gconf.xml.defaults. These defaults still supersede
packaged defaults in /usr/share/gconf/defaults. I don't like to provide
2 ways to do the same thing, especially if it means to diverge from
upstream's documentation.

Regards,
--
 .''`.           Josselin Mouette        /\./\
: :' :           [hidden email]
`. `'                        [hidden email]
   `-  Debian GNU/Linux -- The power of freedom

Reply | Threaded
Open this post in threaded view
|

Re: Please test the experimental gconf2

Gabor Gombas
In reply to this post by Josselin Mouette
On Mon, Nov 14, 2005 at 12:35:41AM +0100, Josselin Mouette wrote:

> First, I hereby proclaim the end of the overly long gconf subtrees.
> Following these suggestions:
> http://www.gnome.org/~lcolitti/gnome-startup/analysis/
> I have merged all gconf directory structures into flat-file sources.
> This means startup and runtime speed is improved, and it also means less
> cluttering on the disk. There is now only one file, named
> %gconf-tree.xml, for each directory structure. The system-wide
> directories are taken care in the postinst, and I have added a Xsession
> script for ~/.gconf.

I've finally upgraded gconf and burned myself. I synchronize my home
directory between two machines daily. Now, there are some gconf settings
(like evolution settings) I DO want to synchronize, and there are others
(like keyboard layout, mixer device etc). that must NOT be synchronized.
With the split structure I could just tell unison the directories it
should ignore but that no longer works with the merged gconf database.

So,

- How can I split the merged %gconf-tree.xml in $HOME/.gconf to the
  pervious directory structure?
- How can I disable the merging of gconf data on a per-user basis?

I think the merging of gconf data under user home directories should be
an opt-in solution and must not be done without the explicit agreement
of the user.

Gabor

--
     ---------------------------------------------------------
     MTA SZTAKI Computer and Automation Research Institute
                Hungarian Academy of Sciences
     ---------------------------------------------------------


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

Reply | Threaded
Open this post in threaded view
|

Re: Please test the experimental gconf2

Josselin Mouette
Le jeudi 24 novembre 2005 à 12:00 +0100, Gabor Gombas a écrit :
> I've finally upgraded gconf and burned myself. I synchronize my home
> directory between two machines daily. Now, there are some gconf settings
> (like evolution settings) I DO want to synchronize, and there are others
> (like keyboard layout, mixer device etc). that must NOT be synchronized.
> With the split structure I could just tell unison the directories it
> should ignore but that no longer works with the merged gconf database.

It looks like a weird setup. Can't you work things out with sabayon
desktop profiles?

> - How can I split the merged %gconf-tree.xml in $HOME/.gconf to the
>   pervious directory structure?

If you remove the %gconf-tree.xml file, you will lose modifications you
made since, but the previous directory structure is still here.

> - How can I disable the merging of gconf data on a per-user basis?
>
> I think the merging of gconf data under user home directories should be
> an opt-in solution and must not be done without the explicit agreement
> of the user.

If some people really want to disable it, I can imagine an opt-out
setup, but you should be aware it's going to become the default in GNOME
2.14 anyway.
--
 .''`.           Josselin Mouette        /\./\
: :' :           [hidden email]
`. `'                        [hidden email]
   `-  Debian GNU/Linux -- The power of freedom

Reply | Threaded
Open this post in threaded view
|

Re: Please test the experimental gconf2

Xavier Bestel
Just for info, I have installed the experimental gconf2 a week ago. I
can feel the difference at startup, and so far no problem.

Thanks,
        Xav



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

Reply | Threaded
Open this post in threaded view
|

Re: Please test the experimental gconf2

Gabor Gombas
In reply to this post by Josselin Mouette
On Thu, Nov 24, 2005 at 12:31:29PM +0100, Josselin Mouette wrote:

> It looks like a weird setup. Can't you work things out with sabayon
> desktop profiles?

I don't think it is weird. Basically I want every software configuration
change I made on one machine to appear automatically on the other
machine too, while leaving hardware-related settings (keyboard, mixer)
unmodified.

I haven't heard about sabayon before, but from a quick read it requires
configuration changes to be made in a separate xnest session while I
want changes in my _current_ session to be detected & transferred to some
transfer medium. I also need a way to explicitely ignore some
configuration items because the hardware _is_ different on the machines
I want to synchronize.

> If you remove the %gconf-tree.xml file, you will lose modifications you
> made since, but the previous directory structure is still here.

Yes, I since figured that out too.

> If some people really want to disable it, I can imagine an opt-out
> setup, but you should be aware it's going to become the default in GNOME
> 2.14 anyway.

I'm not sure it is a good idea. There is a good reason UNIX users always
preferred small per-application config files over big, monolithic
all-in-one solutions.

At least there should be a tool that does the reverse of
gconf-merge-tree so I can split %gconf-tree.xml before synchronization
and re-build it after synchronization.

Gabor

--
     ---------------------------------------------------------
     MTA SZTAKI Computer and Automation Research Institute
                Hungarian Academy of Sciences
     ---------------------------------------------------------


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

Reply | Threaded
Open this post in threaded view
|

Re: Please test the experimental gconf2

Gabor Gombas
In reply to this post by Xavier Bestel
On Thu, Nov 24, 2005 at 02:24:11PM +0100, Xavier Bestel wrote:

> Just for info, I have installed the experimental gconf2 a week ago. I
> can feel the difference at startup, and so far no problem.

Well, I'm an user who is completely ignorant about startup time :-) On
the machine at work, I log in/out roughly once in a month (power outage,
kernel upgrade - there is always something). At home, I do not sit and
wait while the machine boots & autologin completes but instead I go and do
other things, so I again do not really care if the Gnome session takes a
minute shorter or longer to start.

Gabor

--
     ---------------------------------------------------------
     MTA SZTAKI Computer and Automation Research Institute
                Hungarian Academy of Sciences
     ---------------------------------------------------------


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

Reply | Threaded
Open this post in threaded view
|

Re: Please test the experimental gconf2

Josselin Mouette
In reply to this post by Josselin Mouette
The new gconf2 package in experimental, version 2.12.1-5, now features
the possibility to refuse the data migration to the new single-file
layout. This should make it easier for people using scripts based on
the .gconf structure.

It would be nice if some people could test the 2.10 -> 2.12 migration
again.

Regards,
--
 .''`.           Josselin Mouette        /\./\
: :' :           [hidden email]
`. `'                        [hidden email]
   `-  Debian GNU/Linux -- The power of freedom


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

Reply | Threaded
Open this post in threaded view
|

Re: Please test the experimental gconf2

Andrea Vettorello
On 12/19/05, Josselin Mouette <[hidden email]> wrote:
> The new gconf2 package in experimental, version 2.12.1-5, now features
> the possibility to refuse the data migration to the new single-file
> layout. This should make it easier for people using scripts based on
> the .gconf structure.
>
> It would be nice if some people could test the 2.10 -> 2.12 migration
> again.
>

I've installed the experimental version from Sid, and tried with two
different users. On one i've answered "ok" to create a single file
layout and the other to keep the old setting, no troubles encountered
in both cases.


Andrea