--- Begin Message ---
|
Subject: |
gschemas.compiled should not be added to the profile by multiple packages |
|
Date: |
Wed, 22 Mar 2017 09:30:37 +0100 |
|
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.8.0 |
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.
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: gschemas.compiled should not be added to the profile by multiple packages |
|
Date: |
Sun, 27 Dec 2020 01:02:24 +0100 |
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
--- End Message ---