Hi, I just realized why after emerge, some apps don't show up in the gnome menu. It's because portage most of the time puts the .desktop file in /usr/share/applications, and only after that the corresponding executable to /usr/bin/. Detailed Description: Gnome-Menu get's inotified the moment the .desktop file hits the live tree, if it finds an try-exec command it uses it to find out if the application really exists (a feature of the freedesktop.org standard), which fails because emerge hasn't put this command there yet. So to see the new application, a user has to logout/login, which is confusing/unnecessary. This could affect other apps following the freedesktop.org spec, too. A related problem is apps showing up in the menu, but without icon - same reason, but this time /usr/share/pixmaps/ is late. Request: Teach portage to qmerge /usr/share/applications last. Alternative: Find out how to tell running gnome-menus to rescan and do it routinely after emerge. (Touching a file in /usr/share/applications/ does it, but wouldn't be workable as a portage action, I think.) Related Bugs: bug #149035, bug #136213 were bugs I found which could describe the same problem, but not the cause. I imagine many users have this problem but don't know why/don't file a bug.
(In reply to comment #0) > Request: > Teach portage to qmerge /usr/share/applications last. Request - teach Gnome to re-read /usr/share/applications... instead of bring cruft into portage.
This is way beyond the scope of portage itself. Maybe you can convince the ebuild maintainers to write an eclass function to solve it in the postinst phase...
Uhm, which eclass? This affects not only gnome apps, but any app having an .desktop. Should I file a bug against all of them? ;-) How is info page index recreation handled?
Wating for input here.
This is now handled by desktop_database_update in fdo-mime.eclass
