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.