KAuth buildability: new CI architecture

[Martin Gräßlin]

Am 2017-04-16 13:52, schrieb Ben Cooksley:
> On Sun, Apr 16, 2017 at 11:09 PM, Harald Sitter <sitter at 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.

Cheers
Martin