Bug 315452 - put /usr/local/share in front of /usr/share in XDG_DATA_DIRS
Summary: put /usr/local/share in front of /usr/share in XDG_DATA_DIRS
Status: RESOLVED FIXED
Alias: None
Product: plasmashell
Classification: Plasma
Component: general (show other bugs)
Version: 5.17.3
Platform: Debian testing Linux
: NOR normal
Target Milestone: 1.0
Assignee: David Edmundson
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-02-19 14:08 UTC by Gaudenz Steinlin
Modified: 2020-01-09 16:30 UTC (History)
10 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
Patch to update startkde in accordance with XDG and KDEDIRS specifications (2.42 KB, patch)
2013-03-14 16:51 UTC, Woodsman
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Gaudenz Steinlin 2013-02-19 14:08:05 UTC
The startkde script sets the XDG_DATA_DIRS variable to XDG_DATA_DIRS="`kde4-config --prefix`/share:/usr/share:/usr/local/share" if the variable is not set. The default if the variable is not set is to put "/usr/local/share:/usr/share".
The startkde script should honour the preference of /usr/local over /usr so that files provided by the system package managment can be locally overriden without directly modifying them.
If the setting of XDG_DATA_DIRS in startkde is really necessary I suggest to set it to "/usr/local/share:`kde4-config --prefix`/share:/usr/share". 

Reproducible: Always

Steps to Reproduce:
1. copy a .desktop file from /usr/share/applications to /usr/local/share/applications 
2. modify the applications name in /usr/local/share/applications (or any other property in the file)
3.
Actual Results:  
The original name is shown instead of the modified one. 

Expected Results:  
The modified name should be shown in the menu.
Comment 1 Woodsman 2013-03-14 16:51:40 UTC
Created attachment 78072 [details]
Patch to update startkde in accordance with XDG and KDEDIRS specifications

I agree with the original report. The XDG_DATA_DIRS specification says the same thing:

http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html#variables

In startkde the XDG_DATA_DIRS variable should be explicitly set only when KDE is installed in a non standard location, such as /opt. When KDE is installed in /usr then startkde should not be explicitly setting XDG_DATA_DIRS.

I discovered the same basic problem as the OP when I modified my $KDEDIRS variable with an additional directory. Most of the files in that additional directory were not being recognized. Everything work as expected when I commented out the current XDG_DATA_DIRS snippet in startkde. The current startkde snippet works for most use cases only because many people never expand the $KDEDIRS variable and many distros are designed with XDG_DATA_DIRS already set. In the former case there is no damage and in the latter case the snippet never executes.

I am attaching a patch for startkde.cmake in the kde-workspaces sources. The patch contains verbose comments about when to set XDG_DATA_DIRS so future developers are careful about changes.
Comment 2 Christoph Feck 2013-04-14 20:54:17 UTC
Thanks for the patch. Could you create a review request at https://git.reviewboard.kde.org/ for it? I suggest to use kdelibs as reviewer group.

For more information, see
- http://techbase.kde.org/Contribute/Send_Patches
- http://techbase.kde.org/Development/Review_Board
Comment 3 Woodsman 2013-04-15 21:58:30 UTC
I tried creating a review request but I received an error message of "The selected file does not appear to be a diff."
Comment 4 Gaudenz Steinlin 2013-04-20 11:33:49 UTC
(In reply to comment #3)
> I tried creating a review request but I received an error message of "The
> selected file does not appear to be a diff."

How did you create that diff? As explained in http://techbase.kde.org/Development/Review_Board sending a request is best done with the "post-review" helper tool.
Comment 5 Woodsman 2013-04-20 17:52:47 UTC
Standard method: diff -urN

If you want to use the patch then create the review request. :)
Comment 6 Christoph Feck 2013-11-19 02:27:36 UTC
Any progress with the review request?
Comment 7 Rex Dieter 2014-03-13 18:04:48 UTC
https://git.reviewboard.kde.org/r/109675/

Looks related, but that "fix" has it's own set of problems.
Comment 8 sniperrifle2004 2019-11-27 15:01:36 UTC
I just found out that startplasma still does this:

https://github.com/KDE/plasma-workspace/blob/master/startkde/startplasma.cpp#L193

It's so strange, since having the KDE_INSTALL_FULL_DATAROOTDIR first in XDG_DATA_DIRS apparently matters, but not enough to prepend it to an existing value. The swapped /usr/local/share and /usr/share just seems like a mistake to be honest.
Comment 9 Christoph Feck 2019-11-27 20:14:40 UTC
Would you like to submit a diff to https://phabricator.kde.org/differential/diff/create/ to change it? Comment 7 mentions some problems with previous attempts, but these issues might no longer be applicable.
Comment 10 sniperrifle2004 2019-11-27 23:32:15 UTC
Sure, I'll give it a go.
Comment 11 David Edmundson 2020-01-09 16:30:14 UTC
Git commit 3c1a34a26dbdf7c123782746881d914cd47b27b6 by David Edmundson.
Committed on 09/01/2020 at 16:30.
Pushed by davidedmundson into branch 'master'.

[startkde] Drop hack to manually set XDG_DATA_DIRS to the install root

Summary:
For normal distros it doesn't make sense, KDE_INSTALL_FULL_DATAROOTDIR
will be /usr/.

For devs using a prefix startplasma-dev.sh already does this for us only
for the dev setup.

For any other user, it should be their responsibility to adjust it.

It's currently broken anyway, if a user simply installs flatpak that sets this env
earlier in the boot, so this will do nothing. It implies no-oe relies on thisl

It's a relic from 2007 (bd38d59e11548f160efd0918ca5461536ac72349) that doesn't
make sense now.

Test Plan: Compiles

Reviewers: #plasma

Subscribers: plasma-devel

Tags: #plasma

Differential Revision: https://phabricator.kde.org/D26537

M  +0    -8    startkde/startplasma.cpp

https://commits.kde.org/plasma-workspace/3c1a34a26dbdf7c123782746881d914cd47b27b6