Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 264647 - XDG_DATA_DIRS and XDG_CONFIG_DIRS should be explicitly defined in env.d
Summary: XDG_DATA_DIRS and XDG_CONFIG_DIRS should be explicitly defined in env.d
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Freedesktop bugs
URL:
Whiteboard:
Keywords:
: 266430 (view as bug list)
Depends on:
Blocks: 204310
  Show dependency tree
 
Reported: 2009-04-02 15:53 UTC by Maciej Mrozowski
Modified: 2018-02-24 10:57 UTC (History)
8 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Maciej Mrozowski gentoo-dev 2009-04-02 15:53:54 UTC
According to XDG data specification[1], applications should append default values for XDG_DATA_DIRS and XDG_CONFIG_DIRS only when those variables are not defined. Currently Gentoo does not define those variables in env.d at all.
In typical scenario, when only one XDG-aware Desktop Environment is installed - everything works fine, as is such scenario, DE that follows specification. not having found XDG-dirs defined by system, appends default locations:
XDG_DATA_DIRS="/usr/local/share:/usr/share"
XDG_CONFIG_DIRS="/etc/xdg"
Unfortunately, when some DE tries to insufficiently define XDG-dirs, let's say:
XDG_DATA_DIRS="/usr/kde/4.2/share"
it will most likely break every DE, resulting in default locations for desktop files being inaccessible (in menu - missing applications from /usr/local and /usr), because those default locations are not added implicitly.
This is related to bug 204310.

The solution is to explicitly define standard XDG locations in env.d (presumably with some existing  xdg-* related package like xdg-utils). Example layout:

cat /etc/evn.d/01xdg-data-local
XDG_DATA_DIRS="/usr/local/share"
COLON_SEPARATED="XDG_DATA_DIRS XDG_CONFIG_DIRS"

cat /etc/env.d/99xdg-data-base
XDG_DATA_DIRS="/usr/share"
XDG_CONFIG_DIRS="/etc/xdg"

In such case, to properly define DE specific XDG locations, it would be:

cat /etc/env.d/43kdepaths-4.2
[...]
XDG_DATA_DIRS="/usr/kde/4.2/share"

Currently kdelibs needs to explicitly append system-wide /usr/local/share and /usr/share to XDG_DATA_DIRS, which is not desired.

1. http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
Comment 1 Gilles Dartiguelongue gentoo-dev 2009-04-05 22:05:28 UTC
ok I've tested this solution with gdm 2.20.9 and gdm 2.26 and both works as expected with proposed changes. I suggest:
 * 30xdg-data-local
 * 90xdg-data-base

for naming. 30 because it feels not as prio as gcc, binutils or udev settings and 90 because gdm-2.20 series append its path to XDG_DATA_DIRS so it would be named 99xdg-gdm or something like that.
Comment 2 Tomáš Chvátal (RETIRED) gentoo-dev 2009-04-05 22:09:46 UTC
kde agrees, actualy reaver is speaking for kde team in this so treat it as it was already voted as best by kde. If you need our go too :]
Comment 3 Gilles Dartiguelongue gentoo-dev 2009-04-05 22:14:22 UTC
That's what I understood :)
We just need to coordinate the commit of the modified ebuild for xdg data dirs, gdm and kde to avoid regressions by limiting the time window :)
I'll try to get a gdm ebuild ready for tomorrow night (in about 21 hours).
Comment 4 Gilles Dartiguelongue gentoo-dev 2009-04-06 21:49:44 UTC
btw, I don't see a specific ebuild related to xdg-dir besides xdg-user-dirs (but that's another story). How should we go about doing this then ?
Comment 5 Rémi Cardona (RETIRED) gentoo-dev 2009-04-06 22:16:48 UTC
fake ebuild ftw? It's ugly but I don't see another solution...
Comment 6 Tomáš Chvátal (RETIRED) gentoo-dev 2009-04-06 22:24:17 UTC
well we can add it to xdg-utils and depend on it. (might be good solution too)
Comment 7 Ben de Groot (RETIRED) gentoo-dev 2009-04-09 13:52:59 UTC
(In reply to comment #6)
> well we can add it to xdg-utils and depend on it. (might be good solution too)

I agree, speaking for LXDE team here  :-)
Comment 8 Mike Auty (RETIRED) gentoo-dev 2009-04-09 14:38:17 UTC
I just hit this (gnome-do-0.8.1.3 has a typo in the default XDG vars [1]).  I'd go with putting them in xdg-utils, since most anything that needs XDG will pull those in (won't they?)...

[1] https://bugs.launchpad.net/do/+bug/344727
Comment 9 Gilles Dartiguelongue gentoo-dev 2009-04-12 23:11:08 UTC
xdg-utils and gdm changes pushed.
Comment 10 mikopp 2009-04-14 06:46:58 UTC
kde menu's still missing after this change. see bug 266076
Comment 11 Tomáš Chvátal (RETIRED) gentoo-dev 2009-04-14 22:55:14 UTC
This has some reason staying open?
Just asking if there is something more needed to be done.
Comment 12 Maciej Mrozowski gentoo-dev 2009-04-14 23:33:30 UTC
Hmm, probably kdelibs:3.5 still contains redundant XDG_ definitions
Comment 13 Tommaso Pasini 2009-04-16 21:16:36 UTC
Please, add warnings inside the ebuilds, I had gdm ~x86 but xdg-utils stable, and I wasn't able to login inside my session until I found this bug.
Comment 14 Gilles Dartiguelongue gentoo-dev 2009-04-16 21:21:55 UTC
~x86 gdm (2.20.10 that is) depends on proper xdg-utils...
Comment 15 Gilles Dartiguelongue gentoo-dev 2009-04-17 11:50:49 UTC
*** Bug 266430 has been marked as a duplicate of this bug. ***
Comment 16 Fabio Erculiani (RETIRED) gentoo-dev 2009-05-07 09:14:28 UTC
30xdg-data-local and 90xdg-data-base need to be swapped (moving the latter prior to the former). The matter is that if kdelibs-4.x is installed (which provides its own XDG_DATA_DIRS dir) gtk is unable to load icons on some applications (example: gnome-power-manager).

Non-working XDG_DATA_DIRS:
XDG_DATA_DIRS=/usr/local/share:/usr/kde/4.2/share:/usr/share:/usr/kde/3.5/share

Working XDG_DATA_DIRS:
XDG_DATA_DIRS=/usr/share:/usr/kde/4.2/share:/usr/local/share:/usr/kde/3.5/share

This is a blocker for us, patched ebuild will follow.
Comment 17 Fabio Erculiani (RETIRED) gentoo-dev 2009-05-07 09:15:32 UTC
Also, this is a bug also related with kde4 built with USE="kdeprefix"
Comment 18 Gilles Dartiguelongue gentoo-dev 2009-05-07 09:27:32 UTC
you are probably hitting bug #267018.
Inverting *xdg-data* don't make sense as it should work like $PATH. The real bug that is stopping gtk+ from finding icons past kde xdg data dir should be fixed rather than doing this. Would putting kde4 xdg data dir after 90xdg-data-base but before kde3 xdg data dir work too ?
Comment 19 Maciej Mrozowski gentoo-dev 2009-05-12 15:30:18 UTC
About mixing KDE4 and KDE3 - dealing with duplicated menu entries in KDE3 in such case is another problem and just playing with XDG_ won't help here. On of solutions would be like in ArchLinux:
- patch kdelibs3 to on-the-fly replace KDE4 desktop entry names to make them distinguish from KDE3 ones (as for now they just look duplicated in KDE3 session)
- unset KDEDIRS=/usr in KDE3 session (for example in startkde script) - KDE3 goes crazy if KDE4 in installed in /usr and KDEDIRS is set in that location (KDEDIRS is meant to override any resource location)
- being able to run 3rd party KDE4 apps built against kdeprefix-ed KDE4 installation still requires exported KDEDIRS=/usr (preferably globally)
I'm on it, unfortunately health problems stopped me from making any progress in that manner for nearly three weeks.
Comment 20 Maciej Mrozowski gentoo-dev 2009-05-31 20:16:51 UTC
Just one note with regarding this behaviour.

Currently we have:
30xdg-data-local:
XDG_DATA_DIRS="/usr/local/share"
COLON_SEPARATED="XDG_DATA_DIRS XDG_CONFIG_DIRS"

90xdg-data-local:
XDG_DATA_DIRS="/usr/share"
XDG_CONFIG_DIRS="/etc/xdg"

This means, that if anybody puts some DE-specific XDG_CONFIG_DIRS in env.d (that is not needed and even wrong!) it will globally shadow the one that's supposed to be system-wide default (/usr/share), so just in any case please DON'T :)

And it's not needed to be set globally as it's purely DE-specific (and it's supposed to be set in DE startup scripts).

Anyway it's fixed and can be closed now.
Comment 21 Larry the Git Cow gentoo-dev 2018-02-24 10:57:35 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3df07552decade334030ee8b793e40a34a9a2688

commit 3df07552decade334030ee8b793e40a34a9a2688
Author:     Mart Raudsepp <leio@gentoo.org>
AuthorDate: 2018-02-24 10:44:36 +0000
Commit:     Mart Raudsepp <leio@gentoo.org>
CommitDate: 2018-02-24 10:56:49 +0000

    media-libs/mesa: depend on xdg-utils for USE=openmax to not break XDG specs
    
    This is currently necessary due to the installation of 99mesaxdgomx with USE=openmax.
    Ideally we wouldn't depend on xdg-utils as a whole with its perl deps, but
    that's pending changed there. Unbreak things for the not so common case of
    mesa USE=openmax for the time being.
    
    Bug: https://bugs.gentoo.org/635040
    Bug: https://bugs.gentoo.org/264647
    Package-Manager: Portage-2.3.19, Repoman-2.3.6

 media-libs/mesa/mesa-17.1.10.ebuild    | 7 +++++--
 media-libs/mesa/mesa-17.2.8.ebuild     | 5 ++++-
 media-libs/mesa/mesa-17.3.5.ebuild     | 5 ++++-
 media-libs/mesa/mesa-18.0.0_rc4.ebuild | 5 ++++-
 media-libs/mesa/mesa-9999.ebuild       | 5 ++++-
 5 files changed, 21 insertions(+), 6 deletions(-)}