$ guix package -i deluge
Le paquet suivant sera installé :
deluge 2.2.0
guix package: erreur : le profil contient des entrées en conflit pour gtk+
guix package: erreur : première entrée : gtk+@3.24.51 /gnu/store/mkfknbmwcbd39bmsh83hw3xpjmmj77y7-gtk+-3.24.51
guix package: erreur : ... propagé depuis deluge@2.2.0
guix package: erreur : deuxième entrée : gtk+@3.24.51 /gnu/store/nicb9k3h7mvzm2dh91vr6gf6ay05f9ks-gtk+-3.24.51
guix package: erreur : ... propagé depuis gcr@3.41.2
guix package: erreur : ... propagé depuis gnome-keyring@46.2
conseil : Essayez de mettre à jour à la fois `deluge' et `gnome-keyring', ou supprimez-en un du profil.
My apologies for not having this error in English but French, but I solved this issue already by removing gnome-keyring and then installing deluge (and reinstalling gnome-keyring).
This isn’t the first time though and it’s always a conflict with same package of the same version, except located in a different folder.
I just wonder why I keep getting them.
But why does this happen here? The versions seem to be the same.
But the hashes aren’t. Version numbers aren’t very relevant in Guix (their main practical use is to make the CLI feel familiar), only whether the package is identical or not.
I.e. version numbers may be the same but apparently the packages are different (maybe built from different commit or some other thing that causes a difference). The version numbers are there for you to get a general idea of how up to date the package is compared to other versions of the same package in other package management schemes. The thing that matters for Guix (for ensuring compatibility, workability of substitutes, etc) is if the package is completely identical.
Note I’m not an expert and unfortunately I run into this issue as well sometimes.
In my case things worked properly after removing the offending packages (i.e. the ones that had the dependencies) and then running garbage collection on (so the offending different versions are removed) and then guix pull followed by trying to install again.
I honestly don’t know how to solve this more precisely though.
Sorry, a bit late. I had this issue a couple of times due to nvidia grafting the packages. If I imported the packages once with mesa-replace and without you get this kind of confusion. My solution was to refactor mercilessly my packages and ensure they are all going through the same transformations (if needed as I have machines without the nvidia curse).
The replace-mesa does cache the results so will not make duplicates if packages are added multiple times (as is inevitable due to transitive dependencies).