Am 2017-04-17 06:49, schrieb Ben Cooksley:
On Mon, Apr 17, 2017 at 12:48 AM, Martin Gräßlin <mgraess...@kde.org>
wrote:
Am 2017-04-16 13:52, schrieb Ben Cooksley:
On Sun, Apr 16, 2017 at 11:09 PM, Harald Sitter <sit...@kde.org>
wrote:
Not particularly related to the issue at hand (which is probably
polkitqt having meh cmake files), but relocating stuff in general is
suuuuper unreliable and I would absolutely advise against it as it
can
easily screw up test results and builds alike, often in unobvious
ways
(all it takes is a bit of libexec use). Instead, as a general
principle, I would suggest that you get stuff mounted in suitably
stable/consistent/generic paths inside the build containers.
Ultimately what things look like natively on the host file system
shouldn't factor into what they look like in the build environment.
While I have thought of using a consistent path, this would simply
workaround the fact that our binaries are frail and have hardcoded
paths baked into them.
note that this is partially intended for security reasons. E.g.
kscreenlocker starts kcheckpass through a hardcoded path for security
reasons (we want to be sure it's the kcheckpass we created and not a
fakekcheckpass injected by a malicious tool). So overall especially in
plasma lots of Wayland stuff is hardcoding paths for this reason and
partially they are used in testing.
In the case of kscreenlocker this can become a problem when KWin tests
are
run. We have tests verify that locking the screen works on Wayland.
For that
kscreenlocker_greet gets started and that has a hardcoded path as
well. So
if the paths is relocated we test an unsupported setup.
Would it be possible to use relative-to-calling-binary paths?
Simply put: no. That would require quite some engineering effort
especially considering that distros do have the libexec paths different
with some adding the arch into it. This makes it almost impossible to
get it right.
So in the case of kscreenlocker I have absolute zero interest in
re-engineering it to support relative paths. The current code works and
we can just assume that it is there. Anything else requires error
handling and if something goes wrong users have a system which cannot be
unlocked. The risk is not worth the effort.
Cheers
Martin
