Hi! Leo Prikler skribis: > Am Dienstag, den 03.11.2020, 23:46 +0100 schrieb Ludovic Courtès: >> Ludovic Courtès skribis: >> >> > This is not news to us, but as >> > notes, >> > the >> > application menu of desktop environments is not automatically >> > updated >> > when a package is installed or removed. It’d be great if we could >> > somehow notify the desktop environment. >> >> We’ve investigated today on IRC with Maxim and Leo P. and here’s the >> summary of our findings: > Seeing my name thrown around more and more lately makes me blush a > little. Heheh, you provided useful hints! >> The GLib patch below is an attempt to monitor ~/.guix-profile and to >> treat changes to that symlink as if they were changes to >> ~/.guix-profile/share/applications (which contains ‘.desktop’ files.) >> It actually builds but I haven’t tested it yet. :-) >> >> WDYT? > Not having tested it either, I think that we should also listen on > /run/current-system/ (if it exists), so that changes to the system as > done by `reconfigure` are picked up. This includes most importantly > changes to the GNOME ecosystem itself. Like I wrote in the related bug, I think /run/current-system is less important because it typically doesn’t change much: https://issues.guix.gnu.org/35594#6 But I guess I’m also being a bit lazy… Anyhow, I’ve tested the patch in ‘guix system vm gnu/system/examples/desktop.tmpl’, with a ‘glib’ replacement as shown below. I strace’d the user’s gnome-shell and ran: ln -s /run/current-system/profile ~/.guix-profile The trace showed that this led gnome-shell to traverse files in ~/.guix-profile/share (not just the applications/ sub-directory.) I wanted to test ‘guix install’ for real, which meant doing it on ‘guix system vm-image’, but that took too long; so I tried ‘disk-image -t qcow2’ instead but partition.img.drv fails. So I haven’t been able to actually test with ‘guix install’. Anyway, here’s the Guix patch. You need to drop the GLib patch in the right place. Thanks, Ludo’.