| Summary: | XDG_DATA_DIRS and XDG_CONFIG_DIRS should be explicitly defined in env.d | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Maciej Mrozowski <reavertm> |
| Component: | Current packages | Assignee: | Freedesktop bugs <freedesktop-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | bugs.gentoo.09-17, cbm, ikelos, jdaluz, l33tmmx, nikoli, pacho, xenoterracide |
| Priority: | High | ||
| Version: | 2008.0 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: | https://bugs.gentoo.org/show_bug.cgi?id=635040 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 204310 | ||
|
Description
Maciej Mrozowski
2009-04-02 15:53:54 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. 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 :] 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). 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 ? fake ebuild ftw? It's ugly but I don't see another solution... well we can add it to xdg-utils and depend on it. (might be good solution too) (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 :-) 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 xdg-utils and gdm changes pushed. kde menu's still missing after this change. see bug 266076 This has some reason staying open? Just asking if there is something more needed to be done. Hmm, probably kdelibs:3.5 still contains redundant XDG_ definitions 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. ~x86 gdm (2.20.10 that is) depends on proper xdg-utils... *** Bug 266430 has been marked as a duplicate of this bug. *** 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. Also, this is a bug also related with kde4 built with USE="kdeprefix" 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 ? 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. 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. 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(-)} |