Hey,
GConf is finally on the way out, it is being replaced by GSettings/DConf. From a packaging perspective, the following facts are important to know if your package starts using GSettings:
GSettings uses schemas. These are installed as xml files in /usr/share/glib-2.0/schemas. The schemas need to be compiled into binary form using glib-compile-schemas, so you will have to add the following to your spec:
%postun glib-compile-schemas /usr/share/glib-2.0/schemas ||:
%posttrans glib-compile-schemas /usr/share/glib-2.0/schemas ||:
If the schema is ported 1-1 from a GConf schema and uses key names including _ or other characters outside [a-z0-9-], you need to use the --allow-any-name option when calling glib-compile-schemas
You can look at the rawhide evince package for an example.
Matthias
On Sunday 16 May 2010 09:09:11 pm Matthias Clasen wrote:
Hey,
GConf is finally on the way out, it is being replaced by GSettings/DConf. From a packaging perspective, the following facts are important to know if your package starts using GSettings:
GSettings uses schemas. These are installed as xml files in /usr/share/glib-2.0/schemas. The schemas need to be compiled into binary form using glib-compile-schemas, so you will have to add the following to your spec:
%postun glib-compile-schemas /usr/share/glib-2.0/schemas ||:
%posttrans glib-compile-schemas /usr/share/glib-2.0/schemas ||:
If the schema is ported 1-1 from a GConf schema and uses key names including _ or other characters outside [a-z0-9-], you need to use the --allow-any-name option when calling glib-compile-schemas
You can look at the rawhide evince package for an example.
Matthias
And you have a proposal you have sent to the fpc so this can be documented in the packaging guidelines?
Dennis
Hi.
On Sun, 16 May 2010 22:09:11 -0400, Matthias Clasen wrote:
%postun glib-compile-schemas /usr/share/glib-2.0/schemas ||:
%posttrans glib-compile-schemas /usr/share/glib-2.0/schemas ||:
I sure hope this is solved somewhat intelligently and does not compile each and every schema on every installed package. Whatever it is that gconf is doing on updates/installs now is bad enough.
Why can the package not come with it's schema precompiled?
On Mon, 2010-05-17 at 11:10 +0200, Ralf Ertzinger wrote:
Hi.
On Sun, 16 May 2010 22:09:11 -0400, Matthias Clasen wrote:
%postun glib-compile-schemas /usr/share/glib-2.0/schemas ||:
%posttrans glib-compile-schemas /usr/share/glib-2.0/schemas ||:
I sure hope this is solved somewhat intelligently and does not compile each and every schema on every installed package. Whatever it is that gconf is doing on updates/installs now is bad enough.
Yes, it does compole all schemas in that directory into a single binary.
Why can the package not come with it's schema precompiled?
Because they all go into a single binary file.
On Mon, 2010-05-17 at 12:49 +0200, Ralf Ertzinger wrote:
Hi.
On Mon, 17 May 2010 06:39:14 -0400, Matthias Clasen wrote:
Yes, it does compole all schemas in that directory into a single binary.
Are those files in size comparable to the current gconf files?
I haven't done extensive experiments. Maybe you want to ?
Matthias Clasen wrote:
On Mon, 2010-05-17 at 11:10 +0200, Ralf Ertzinger wrote:
I sure hope this is solved somewhat intelligently and does not compile each and every schema on every installed package. Whatever it is that gconf is doing on updates/installs now is bad enough.
Yes, it does compole all schemas in that directory into a single binary.
Why can the package not come with it's schema precompiled?
Because they all go into a single binary file.
Yuck! Hello, registry! :-/
What's next? Dumping the data into the same binary as the infamous registry does?
Kevin Kofler
On 05/21/2010 06:59 AM, Kevin Kofler wrote:
Matthias Clasen wrote:
Because they all go into a single binary file.
Yuck! Hello, registry! :-/
What's next? Dumping the data into the same binary as the infamous registry does?
Kevin,
Can you drop with the habit of throwing around inflammatory comments? It serves no constructive purpose. We all understand that love KDE but this is hardly the way to promote it. If you have genuinely concerns about design or implementation of gsettings, take it upstream. If you don't care and I suspect you really don't. then just ignore such threads and concentrate on what you are actually interested about.
Rahul
On Fri, 2010-05-21 at 03:29 +0200, Kevin Kofler wrote:
Matthias Clasen wrote:
On Mon, 2010-05-17 at 11:10 +0200, Ralf Ertzinger wrote:
I sure hope this is solved somewhat intelligently and does not compile each and every schema on every installed package. Whatever it is that gconf is doing on updates/installs now is bad enough.
Yes, it does compole all schemas in that directory into a single binary.
Why can the package not come with it's schema precompiled?
Because they all go into a single binary file.
Yuck! Hello, registry! :-/
What's next? Dumping the data into the same binary as the infamous registry does?
That was a cheap shot unsubstantiated by facts. What makes you think combining the data with the schemas would come next? In the absence of that, the sysadmin can easily regenerate the compiled schema file if it becomes corrupt for any reason.
Kevin Kofler píše v Pá 21. 05. 2010 v 03:29 +0200:
Matthias Clasen wrote:
On Mon, 2010-05-17 at 11:10 +0200, Ralf Ertzinger wrote:
Why can the package not come with it's schema precompiled?
Because they all go into a single binary file.
Yuck! Hello, registry! :-/
What's next?
Looking at existing practice, nothing too interesting. Look at ksycoca, it does something very similar. Mirek
Miloslav Trmač wrote:
Looking at existing practice, nothing too interesting. Look at ksycoca, it does something very similar.
But the sycoca doesn't actually operate on config files. Yes, the "co" stands for "configuration", but the "system configuration cache" is basically a database of information contained in .desktop files (including, but not limited to, those of KDE-specific services), KConfig doesn't use the sycoca.
Kevin Kofler
On 21 May 2010 02:29, Kevin Kofler kevin.kofler@chello.at wrote:
What's next? Dumping the data into the same binary as the infamous registry does?
Dude, this doesn't fit with the "be excellent to each other" ideology.
Richard.
Kevin Kofler píše v Pá 21. 05. 2010 v 11:27 +0200:
Miloslav Trmač wrote:
Looking at existing practice, nothing too interesting. Look at ksycoca, it does something very similar.
But the sycoca doesn't actually operate on config files. Yes, the "co" stands for "configuration", but the "system configuration cache" is basically a database of information contained in .desktop files
... and the gsettings file will be a binary cache of information contained in schema files. I haven't seen any mention of storing the actual configuration in the binary file. Mirek
-
Dennis Gilmore -
Kevin Kofler -
Matt McCutchen -
Matthias Clasen -
Miloslav Trmač -
Rahul Sundaram -
Ralf Ertzinger -
Richard Hughes