KAuth buildability: new CI architecture

[Martin Gräßlin]

Am 2017-04-17 06:49, schrieb Ben Cooksley:
> On Mon, Apr 17, 2017 at 12:48 AM, Martin Gräßlin <mgraesslin at kde.org> 
> wrote:
>> 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.
> 
> 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