Install hook

Install hook

[Florian Pelz]

Hello,

Currently my ~/.guix-profile/share/glib-2.0/schemas/gschemas.compiled
file contains only GSettings from one package. Guix warns about
“arbitrarily choosing” this file when installing a package. This is
bad; gschemas.compiled should be recreated on package install to
include all GSettings stored in the Guix profile.

Arch Linux uses hooks to compile GSettings schemas after installing a
package.

https://git.archlinux.org/svntogit/packages.git/tree/trunk/glib-compile-schemas.hook?h=packages/glib2

Am I correct in that Guix does not support install hooks? I believe
install hooks are the proper way to solve this. This affects more
than just GSettings.

Regards,
Florian

Re: Install hook

[John Darrington]

[-- Attachment #1: Type: text/plain, Size: 1379 bytes --]

Hello Florian,

I agree that this is a problem.  It has been discussed before, and various 
solutions have been suggested, but I don't think install hooks was one of
them.

Can you elaborate on your idea?  What would an install hook do, and how would
it work?

J'


On Sun, Mar 19, 2017 at 11:30:48AM +0100, Florian Pelz wrote:
     Hello,
     
     Currently my ~/.guix-profile/share/glib-2.0/schemas/gschemas.compiled
     file contains only GSettings from one package. Guix warns about
     ???arbitrarily choosing??? this file when installing a package. This is
     bad; gschemas.compiled should be recreated on package install to
     include all GSettings stored in the Guix profile.
     
     Arch Linux uses hooks to compile GSettings schemas after installing a
     package.
     
     https://git.archlinux.org/svntogit/packages.git/tree/trunk/glib-compile-schemas.hook?h=packages/glib2
     
     Am I correct in that Guix does not support install hooks? I believe
     install hooks are the proper way to solve this. This affects more
     than just GSettings.
     
     Regards,
     Florian
     

-- 
Avoid eavesdropping.  Send strong encrypted email.
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: Install hook

[Julien Lepiller]

I think install hooks are scripts run after each package installation,
that are provided by the package itself. We already have a similar
mechanism that takes place when building the user's profile. See
http://git.savannah.gnu.org/cgit/guix.git/tree/guix/profiles.scm.
For instance, we build a icon-theme.cache cache file for every icon
theme in the user's profile.

I have seen references to gschemas.compiled in our
gtk-or-glib-build-system. Currently we build the file in each package,
which means that only one version will be present in the user's profile
if they install more that one package containing this file. I believe
gschemas.compiled contains important information about some graphical
packages, and in our current system, only one package can be referenced
that way.

I think we should make sure that this file is never present in the
output of a package, and add a function to build it in profiles.scm.

Does it make any sense?

On Sun, 19 Mar 2017 12:23:39 +0100
John Darrington <john@darrington.wattle.id.au> wrote:

> I agree that this is a problem.  It has been discussed before, and
> various solutions have been suggested, but I don't think install
> hooks was one of them.
> 
> Can you elaborate on your idea?  What would an install hook do, and
> how would it work?

Re: Install hook

[pelzflorian (Florian Pelz)]

On 03/19/2017 01:14 PM, Julien Lepiller wrote:
> I think install hooks are scripts run after each package installation,
> that are provided by the package itself. We already have a similar
> mechanism that takes place when building the user's profile. See
> http://git.savannah.gnu.org/cgit/guix.git/tree/guix/profiles.scm.
> For instance, we build a icon-theme.cache cache file for every icon
> theme in the user's profile.
> 
> I have seen references to gschemas.compiled in our
> gtk-or-glib-build-system. Currently we build the file in each package,
> which means that only one version will be present in the user's profile
> if they install more that one package containing this file. I believe
> gschemas.compiled contains important information about some graphical
> packages, and in our current system, only one package can be referenced
> that way.
> 
> I think we should make sure that this file is never present in the
> output of a package, and add a function to build it in profiles.scm.
> 
> Does it make any sense?
> 

Yes, exactly. These profile hooks look similar to what I meant.

Re: Install hook

[John Darrington]

[-- Attachment #1: Type: text/plain, Size: 3226 bytes --]

The problem as I understand it is as follows:

Two (or more) packages both contain a file: /gnu/store/.../xyz/foo

So long as those two packages are not both installed into the same profile at
the same time, this is not a problem.  However if the user chooses to 
install both packages concurrently, then there is a potential conflict and
Guix "resolves" this conflict by arbitrarily choosing the xyz/foo from one
package or the other.

One could put a "hook" on package A which (through some method) says: "When
this package (A) is installed, then the xyz/foo file from THIS package must
be the one installed into the profile, and not any other one."

That will work fine so long as only package A has such a hook.  But what 
happens if package B also contains an identical hook?   Both packages' hooks
will then insist that their xyz/foo is the one which must be installed.

Nothing will have been solved.  There will still be a conflict, just shifted
up a level.


The issue as I see it is that neither file is the "right" one to install - 
or to put it another way - BOTH are the right ones.

The solutions which I think have been discussed previously are:

1.  Add an option to the "guix package --install" command to allow the user
to specify which packages' files should take priority.

2.  Use some kind of heuristic based on date installed and other info to
guess which one is "right".

3.  ... probably some other suggestions which I've probably forgotten.


Also, I think we talked about consolidating the warning messages when these
conflicts occur, so that a less overwhelming number of them are emitted.

J'



On Sun, Mar 19, 2017 at 01:50:08PM +0100, pelzflorian (Florian Pelz) wrote:
     On 03/19/2017 01:14 PM, Julien Lepiller wrote:
     > I think install hooks are scripts run after each package installation,
     > that are provided by the package itself. We already have a similar
     > mechanism that takes place when building the user's profile. See
     > http://git.savannah.gnu.org/cgit/guix.git/tree/guix/profiles.scm.
     > For instance, we build a icon-theme.cache cache file for every icon
     > theme in the user's profile.
     > 
     > I have seen references to gschemas.compiled in our
     > gtk-or-glib-build-system. Currently we build the file in each package,
     > which means that only one version will be present in the user's profile
     > if they install more that one package containing this file. I believe
     > gschemas.compiled contains important information about some graphical
     > packages, and in our current system, only one package can be referenced
     > that way.
     > 
     > I think we should make sure that this file is never present in the
     > output of a package, and add a function to build it in profiles.scm.
     > 
     > Does it make any sense?
     > 
     
     Yes, exactly. These profile hooks look similar to what I meant.
     
     

-- 
Avoid eavesdropping.  Send strong encrypted email.
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: Install hook

[pelzflorian (Florian Pelz)]

[-- Attachment #1.1: Type: text/plain, Size: 2297 bytes --]

On 03/19/2017 02:14 PM, John Darrington wrote:
> The problem as I understand it is as follows:
> 
> Two (or more) packages both contain a file: /gnu/store/.../xyz/foo
> 
> So long as those two packages are not both installed into the same profile at
> the same time, this is not a problem.  However if the user chooses to 
> install both packages concurrently, then there is a potential conflict and
> Guix "resolves" this conflict by arbitrarily choosing the xyz/foo from one
> package or the other.
> 
> One could put a "hook" on package A which (through some method) says: "When
> this package (A) is installed, then the xyz/foo file from THIS package must
> be the one installed into the profile, and not any other one."
> 
> That will work fine so long as only package A has such a hook.  But what 
> happens if package B also contains an identical hook?   Both packages' hooks
> will then insist that their xyz/foo is the one which must be installed.
> 
> Nothing will have been solved.  There will still be a conflict, just shifted
> up a level.
> 
> 
> The issue as I see it is that neither file is the "right" one to install - 
> or to put it another way - BOTH are the right ones.
> 
> The solutions which I think have been discussed previously are:
> 
> 1.  Add an option to the "guix package --install" command to allow the user
> to specify which packages' files should take priority.
> 
> 2.  Use some kind of heuristic based on date installed and other info to
> guess which one is "right".
> 
> 3.  ... probably some other suggestions which I've probably forgotten.
> 
> 
> Also, I think we talked about consolidating the warning messages when these
> conflicts occur, so that a less overwhelming number of them are emitted.
> 
> J'
> 

No, normally gschemas.compiled is one file storing information about all
GSettings application. It must thus be created from files provided by
multiple packages.

For example, gnome-calculator ships

org.gnome.calculator.gschema.xml

and gnome-maps ships

org.gnome.Maps.gschema.xml

and from both source files a file gschemas.compiled needs to be created
when gnome-calculator and gnome-maps are installed to the same profile.
This single file then stores settings of both packages.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Install hook

[John Darrington]

[-- Attachment #1: Type: text/plain, Size: 1424 bytes --]

On Sun, Mar 19, 2017 at 02:41:09PM +0100, pelzflorian (Florian Pelz) wrote:

     No, normally gschemas.compiled is one file storing information about all
     GSettings application. It must thus be created from files provided by
     multiple packages.
     
     For example, gnome-calculator ships
     
     org.gnome.calculator.gschema.xml
     
     and gnome-maps ships
     
     org.gnome.Maps.gschema.xml
     
     and from both source files a file gschemas.compiled needs to be created
     when gnome-calculator and gnome-maps are installed to the same profile.
     This single file then stores settings of both packages.


I think I see what you are saying:  gschemas.compiled should not be part of the
the package derivation, but should be part of the profile derivation.

So then guix package --install or guix environment would need to run the necessary
stuff to create it.

I guess that could work, but would work probably need some changes at quite a low
level.

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?

J'
     



-- 
Avoid eavesdropping.  Send strong encrypted email.
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: Install hook

[Ricardo Wurmus]

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

> On 03/19/2017 01:14 PM, Julien Lepiller wrote:
>> I think install hooks are scripts run after each package installation,
>> that are provided by the package itself. We already have a similar
>> mechanism that takes place when building the user's profile. See
>> http://git.savannah.gnu.org/cgit/guix.git/tree/guix/profiles.scm.
>> For instance, we build a icon-theme.cache cache file for every icon
>> theme in the user's profile.
>> 
[…]
>> I think we should make sure that this file is never present in the
>> output of a package, and add a function to build it in profiles.scm.
>> 
>> Does it make any sense?
>> 
>
> Yes, exactly. These profile hooks look similar to what I meant.

Would you like to give it a try to add a profile hook for building
“gschemas.compiled” once for all packages in a given profile?

Please also email a summary to bug-guix@gnu.org so that we can keep
track of this.

-- 
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: Install hook

[pelzflorian (Florian Pelz)]

On 03/21/2017 09:11 AM, Ricardo Wurmus wrote:
> 
> Would you like to give it a try to add a profile hook for building
> “gschemas.compiled” once for all packages in a given profile?
> 

I’ll take a closer look at the code and try it. Since packages are
shipped as part of Guix anyway, one profile hook in Guix maybe is not
worse than allowing hooks to be added to e.g. the glib package in this case.

> Please also email a summary to bug-guix@gnu.org so that we can keep
> track of this.
> 

Will do.

Re: Install hook

[Florian Pelz]

On Tue, 2017-03-21 at 11:06 +0100, pelzflorian (Florian Pelz) wrote:
> On 03/21/2017 09:11 AM, Ricardo Wurmus wrote:
> > 
> > Would you like to give it a try to add a profile hook for building
> > “gschemas.compiled” once for all packages in a given profile?
> > 
> 
> I’ll take a closer look at the code and try it. Since packages are
> shipped as part of Guix anyway, one profile hook in Guix maybe is not
> worse than allowing hooks to be added to e.g. the glib package in this case.
> 
> > Please also email a summary to bug-guix@gnu.org so that we can keep
> > track of this.
> > 
> 
> Will do.
> 

Sorry. I’m feeling a little stupid. GSettings checks each entry in
XDG_DATA_DIRS for a gschemas.compiled file, so compiling the settings
for each package individually does work. The issue with the app I was
trying to run was elsewhere.

Now, all GSettings could still be compiled in a profile hook to a
single gschemas.compiled file to eliminate the annoying warning message
about “arbitrarily choosing” one of them. I have seen an mlet for the
first time today, so I’m not going to fix this. I’m also not sure if
this is really better than what (guix build glib-or-gtk-build-system)
does.

I’m also not going to file a bug since I’m not sure if we even want to
change the current method.