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.
"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
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
"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
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
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
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