gschemas.compiled should not be added to the profile by multiple packages

  • Done
  • quality assurance status badge
Details
3 participants
  • Federico Beffa
  • Leo Prikler
  • pelzflorian (Florian Pelz)
Owner
unassigned
Submitted by
pelzflorian (Florian Pelz)
Severity
normal
P
P
pelzflorian (Florian Pelz) wrote on 22 Mar 2017 09:30
(address . bug-guix@gnu.org)
aa0dccec-4541-25af-9606-9485aae0ceb4@pelzflorian.de
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:

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:
Toggle quote (5 lines)
> 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.
F
F
Federico Beffa wrote on 23 Mar 2017 17:20
(name . pelzflorian (Florian Pelz))(address . pelzflorian@pelzflorian.de)(address . 26215@debbugs.gnu.org)
8760j0nevq.fsf@lupo.i-did-not-set--mail-host-address--so-tickle-me
"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> writes:

Toggle quote (17 lines)
> 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
P
P
pelzflorian (Florian Pelz) wrote on 23 Mar 2017 20:25
(name . Federico Beffa)(address . beffa@ieee.org)(address . 26215@debbugs.gnu.org)
724c4428-dcbe-334f-227c-987f531454e1@pelzflorian.de
On 03/23/2017 05:20 PM, Federico Beffa wrote:
Toggle quote (6 lines)
> 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
F
F
Federico Beffa wrote on 24 Mar 2017 08:28
(name . pelzflorian (Florian Pelz))(address . pelzflorian@pelzflorian.de)(address . 26215@debbugs.gnu.org)
87k27fi15j.fsf@lupo.i-did-not-set--mail-host-address--so-tickle-me
"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> writes:

Toggle quote (10 lines)
> 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
L
L
Leo Prikler wrote on 22 Dec 2020 21:49
Re: gschemas.compiled should not be added to the profile by multiple packages
(address . 26215@debbugs.gnu.org)
2df15184d0776c75bb37052bd40f76b59e742e95.camel@student.tugraz.at
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):
Toggle quote (10 lines)
> 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.)

Toggle quote (9 lines)
> 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

P
P
pelzflorian (Florian Pelz) wrote on 27 Dec 2020 01:02
(name . Leo Prikler)(address . leo.prikler@student.tugraz.at)
20201227000224.uhthhfoeaov5odni@pelzflorian.localdomain
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
L
L
Leo Prikler wrote on 27 Dec 2020 01:26
(name . pelzflorian (Florian Pelz))(address . pelzflorian@pelzflorian.de)(address . 26215-done@debbugs.gnu.org)
0f63f105c38dab2bb3e4440803c50f3a5049862b.camel@student.tugraz.at
Hello Florian,

Am Sonntag, den 27.12.2020, 01:02 +0100 schrieb pelzflorian (Florian
Pelz):
Toggle quote (13 lines)
> [...]
> 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
Closed
?
Your comment

This issue is archived.

To comment on this conversation send an email to 26215@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 26215
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch