bug#26215: gschemas.compiled should not be added to the profile by multiple packages

bug#26215: gschemas.compiled should not be added to the profile by multiple packages

[pelzflorian (Florian Pelz)]

Currently multiple packages contain the file
share/glib-2.0/schemas/gschemas.compiled (which is built by
glib-or-gtk-build-system). Doing so *works* (because each package’s
share directory in the Store is part of the XDG_DATA_DIRS environment
variable, GSettings looks for settings in each of the gschemas.compiled
files in the Store) but leads to *warnings* because only one package’s
gschemas.compiled can be added to the profile at the same time.

To avoid these misleading warnings, either
· no package’s gschemas.compiled should go to the profile on
  install *or*
· gschemas.compiled should not be created for each package by
  glib-or-gtk-build-system, instead it should be created only once
  in each profile by a profile hook from the GSettings data of all
  packages in the manifest,
· or something else?

This bug report follows a discussion here:
https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00552.html

Is it easily possible to prevent a file from going from the Store to a
profile?

As for the other possible solution using a profile hook, John Darrington
asked:
> But what would happen if one had for example gnome-calculator in the
> system profile,
> and gnome-maps in the user profile?  Would it work under those
> circumstances?

A profile hook for gschemas.compiled would eliminate half the purpose of
glib-or-gtk-build-system I believe… It would still be used for setting
GTK_PATH GTK+ modules.

bug#26215: gschemas.compiled should not be added to the profile by multiple packages

[Federico Beffa]

"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> writes:

> Currently multiple packages contain the file
> share/glib-2.0/schemas/gschemas.compiled (which is built by
> glib-or-gtk-build-system). Doing so *works* (because each package’s
> share directory in the Store is part of the XDG_DATA_DIRS environment
> variable, GSettings looks for settings in each of the gschemas.compiled
> files in the Store) but leads to *warnings* because only one package’s
> gschemas.compiled can be added to the profile at the same time.
>
> To avoid these misleading warnings, either
> · no package’s gschemas.compiled should go to the profile on
>   install *or*
> · gschemas.compiled should not be created for each package by
>   glib-or-gtk-build-system, instead it should be created only once
>   in each profile by a profile hook from the GSettings data of all
>   packages in the manifest,
> · or something else?

Note that if you mix GTK-2 and GTK-3 schemas many applications will
crash.  The glib-or-gtk-build-system tries to avoid mixing the two.

Fede

bug#26215: gschemas.compiled should not be added to the profile by multiple packages

[pelzflorian (Florian Pelz)]

On 03/23/2017 05:20 PM, Federico Beffa wrote:
> Note that if you mix GTK-2 and GTK-3 schemas many applications will
> crash.  The glib-or-gtk-build-system tries to avoid mixing the two.
> 
> Fede
> 

I believe you are confusing schemas and modules. GSettings schemas come
from GLib and both GTK+ 2 and GTK+ 3 use the same GLib.

Regards,
Florian

bug#26215: gschemas.compiled should not be added to the profile by multiple packages

[Federico Beffa]

"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> writes:

> On 03/23/2017 05:20 PM, Federico Beffa wrote:
>> Note that if you mix GTK-2 and GTK-3 schemas many applications will
>> crash.  The glib-or-gtk-build-system tries to avoid mixing the two.
>> 
>> Fede
>> 
>
> I believe you are confusing schemas and modules. GSettings schemas come
> from GLib and both GTK+ 2 and GTK+ 3 use the same GLib.

You're probably right.  I only remember quite vaguely that, while
developing the build system and experimenting, I was seeing crashes due
to GTK+ applications seeing stuff from the wrong version.  I thought
that this could be relevant here, but maybe not.

Regards,
Fede

bug#26215: gschemas.compiled should not be added to the profile by multiple packages

[Leo Prikler]

Hello Florian,

I'm writing you, because you've filed issue #26215 against Guix (see
[1] for full context).

Am Mittwoch, den 22.03.2017, 09:30 +0100 schrieb pelzflorian (Florian
Pelz):
> Currently multiple packages contain the file
> share/glib-2.0/schemas/gschemas.compiled (which is built by
> glib-or-gtk-build-system). Doing so *works* (because each package’s
> share directory in the Store is part of the XDG_DATA_DIRS environment
> variable, GSettings looks for settings in each of the
> gschemas.compiled
> files in the Store) but leads to *warnings* because only one
> package’s
> gschemas.compiled can be added to the profile at the same time.

"Currently" is perhaps a bit misleading in this context, given that
this message is three years old, but I suppose many packages still
contain compiled GSettings schemas.  (That's one of the reasons so many
packages use glib:bin after all.)

> To avoid these misleading warnings, either
> · no package’s gschemas.compiled should go to the profile on
>   install *or*
> · gschemas.compiled should not be created for each package by
>   glib-or-gtk-build-system, instead it should be created only once
>   in each profile by a profile hook from the GSettings data of all
>   packages in the manifest,
> · or something else?

Modern Guix does have a profile hook, which IIUC will be the one that's
picked upon conflict resolution.  Should we still make an effort to
remove compiled GSettings schemas where they exist, or can we mark this
bug as resolved?

Regards,
Leo

[1] http://issues.guix.gnu.org/26215

bug#26215: gschemas.compiled should not be added to the profile by multiple packages

[pelzflorian (Florian Pelz)]

Hello Leo!  Thank you for going through old issues!

So the issue appears to be fixed by commit
de136f3ee7878dea139e751b7e4ca04c2542c91d (from year 2018) making sure
a gschemas.compiled encompassing all packages in a Guix profile gets
created.  Reverting that commit does not print warnings today (I don’t
know why), but still causes choosing one of the packages’
gschemas.compiled over the other.

For normal usage, creating individual, per-package gschemas.compiled
files in glib-or-gtk-build-system probably is *useless*.  Checking the
utility is hard though because I have not found a package that does
not create a per-package gschemas.compiled in their build phase
anyway.

I think the bug is done.  Purging the gschemas.compiled files from all
packages would need to be done in an extra phase for many build
systems (glib-or-gtk build system, cmake build system, meson build
system) that would be useless when a package does not use glib.  It is
difficult.  Also the gschemas.compiled files are small in size.  Some
people maybe even do or could rely on the per-package
gschemas.compiled file in self-written setups that do not use Guix
profiles/environments.

Closing.

Regards,
Florian

bug#26215: gschemas.compiled should not be added to the profile by multiple packages

[Leo Prikler]

Hello Florian,

Am Sonntag, den 27.12.2020, 01:02 +0100 schrieb pelzflorian (Florian
Pelz):
> [...]
> I think the bug is done.  Purging the gschemas.compiled files from
> all
> packages would need to be done in an extra phase for many build
> systems (glib-or-gtk build system, cmake build system, meson build
> system) that would be useless when a package does not use glib.  It
> is
> difficult.  Also the gschemas.compiled files are small in size.  Some
> people maybe even do or could rely on the per-package
> gschemas.compiled file in self-written setups that do not use Guix
> profiles/environments.
> 
> Closing.
Thanks for formally closing this bug.  As far as purging the files is
concerned, we do already remove GTK icon caches from packages all over
the place, that would otherwise require gtk+:bin as native input, so it
*is* an option for saving a little space here and there.  That being
said, it is not strictly necessary, just an option if anyone is
sufficiently bored.

Regards,
Leo