Bug 315452

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.

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

I tried creating a review request but I received an error message of "The selected file does not appear to be a diff."

(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.

Standard method: diff -urN

If you want to use the patch then create the review request. :)

Any progress with the review request?

https://git.reviewboard.kde.org/r/109675/

Looks related, but that "fix" has it's own set of problems.

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.

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.

Sure, I'll give it a go.

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