Bug 394371 - gdm sets XDG_DATA_DIRS, KDE's kcontrol is empty, K-Menu lacks any KDE apps
Summary: gdm sets XDG_DATA_DIRS, KDE's kcontrol is empty, K-Menu lacks any KDE apps
Status: RESOLVED DUPLICATE of bug 300678
Alias: None
Product: openSUSE 10.3
Classification: openSUSE
Component: GNOME (show other bugs)
Version: Final
Hardware: i686 openSUSE 10.3
: P5 - None : Blocker (vote)
Target Milestone: ---
Assignee: E-mail List
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-05-25 20:14 UTC by James Carter
Modified: 2008-05-30 21:44 UTC (History)
0 users

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description James Carter 2008-05-25 20:14:25 UTC
We give our users a choice of Gnome, KDE3 and XFCE desktops, and use gdm as the display manager.  After we upgraded to OpenSuSE 10.3 (which has gdm-2.20.0) all KDE users complained that KDE apps (such as k3b, kate, and all other KDE-specific apps) were missing from the K-Menu (main menu), and when they right-click on the desktop background and select "Configure Desktop", a dialog box appears entitled, correctly, "Blank Page".  The Chairman and other senior faculty were not pleased.
    When kbuildsycoca runs, it relies on XDG_DATA_DIRS to find the .desktop files of the apps, or if this is not set, it uses a KDE-specific default including /opt/kde3/share, which is where the KDE-specific apps have their .desktop files.  Starting around 2.20.0, gdm sets XDG_DATA_DIRS to /usr/local/share/:/usr/share:/usr/share/gdm/, preventing kbuildsycoca from finding the KDE .desktop files and related configuration files, which causes our symptom.  Due to the way our startup files go, only a few users (if any) get the benefit of /etc/profile.d/xdg-environment.sh.  
    My first request is that gdm leave XDG_DATA_DIRS alone, i.e unset.  URL: http://bugzilla.gnome.org/show_bug.cgi?id=534722
    Assuming that Gnome will not be too swift fixing this bug/feature, my suggestion to SuSE is to pro-actively unset XDG_DATA_DIRS in /etc/X11/xdm/Xsession (which /etc/gdm/Xsession execs), so each Desktop Environment will use its individual default value, as it was in SuSE 10.2 and previously.
    In my environment my Gnome and XFCE users occasionally use KDE apps such as k3b and Kdevelop, and I think it's user-friendly to include them in the menu, so I've hacked Xsession to unset XDG_DATA_DIRS, then source /etc/profile.d/xdg-environment.sh
    Also, after the fix the users' incomplete caches (ksycoca) will persist, so I test if /var/tmp/kdecache-$USER/ksycoca is older than the hacked Xsession, and if so, I remove the whole cache directory, causing the cache to be rebuilt with the complete set of .desktop files.
Comment 1 JP Rosevear 2008-05-28 13:10:30 UTC
This is already fixed in suse.

*** This bug has been marked as a duplicate of bug 300678 ***
Comment 2 James Carter 2008-05-30 21:44:41 UTC
I see the discussion in bug 300678 about why /usr/share/gdm[/applications] needs to be appended to XDG_DATA_DIRS, so gdm-specific .desktop files can be made available, like the one that starts Xnest to be managed by the current gdm.  But if /etc/profile.d/xdg-environment.sh doesn't get run for any reason (as is frequent at our site), XDG_DATA_DIRS would never get set to include all actually installed applications (menu) directories such as KDE.  I do recommend that it should be run pro-actively in Xsession, before the various profile files are sourced.  This is how I've modified Xsession on my site.
    Beware, although bug 300678 has extensive discussion of avoiding duplicate directories in /etc/profile.d/xdg-environment.sh, the current version from aaa_base-10.3-90.2 will duplicate everything if run twice. 
    So I agree that 304371 is a duplicate of 300678 (sorry that I didn't use XDG_DATA_DIRS in my keyword search but I hadn't discovered the cause at that time).  But I think the solution in 300678 (modifying /etc/profile.d/xdg-environment.sh to never bypass setting XDG_DATA_DIRS) is not enough to solve the problem for all users, specifically my users.