Hi, thanks for the patch.
Unfortunately, that way is not acceptable. Long story short, please make it a regular input. The reasoning is below: Guix has better modularity than most of the other distributions that exist. One of the main uses of modularity is isolation. If one module uses something internally, another module must not be disturbed by that fact. If (executable) package Q requires (library) package B@0.0.1 internally and (executable) package R requires (library) package B@0.0.2 internally then it works just fine to install both Q and R into the same profile. Why? Because B is not propagated into the profile (usually when B is an implementation detail of Q and R and not part of their public interface). If, on the other hand, B were propagated then the profile would not be able to build because the two Bs would conflict. Debian, Gentoo, Redhat etcetc are different in that they basically ONLY have propagated-inputs and don't have regular inputs. They don't have the concept of an "internal" dependency. All their dependencies are external, changing the interface. Looking at https://fossies.org/linux/glib/gio/gio-launch-desktop.c , gio-launch-desktop is very small and not connected to anything else. Propagating it, with all the versioning problems that introduces, would be unwise. I propose instead to make glib bin a regular input of pcmanfm-qt and then substitute* the entire path to gio-launch-desktop in it inside a phase of pcmanfm-qt. As a rule of thumb, if something that a regular user would have never heard of ("glib" "bin" ... ???) makes it directly into his profile (by propagation), it's probably the wrong thing to do.
pgpOFvLWsR5a4.pgp
Description: OpenPGP digital signature
