4.x transition blockage - workspace libs

[Michael Palimaka]

On 07/22/2014 06:10 AM, Martin Gräßlin wrote:
> On Tuesday 22 July 2014 05:28:36 Michael Palimaka wrote:
>> On 07/18/2014 06:54 PM, Harald Sitter wrote:
>>> On Thu, Jul 17, 2014 at 1:37 PM, Michael Palimaka <kensington at gentoo.org> 
> wrote:
>>>>> I  just discused this with mgraesslin on IRC and he's fine with adding
>>>>> a compatibility build flag to 4.x that makes it only install the
>>>>> necessary libraries to avoid file conflicts with plasma-workspace 5.
>>>>>
>>>>> Does that sounds suitable for gentoo and if so, do you guys want to
>>>>> come up with a patch? :)
>>>>
>>>> I'm very interested in this, but what did you have in mind - a collision
>>>> is a collision, right?
>>>
>>> As far as I can tell the colliding bits are:
>>> a) certain binaries/data/nonesense
>>> b) all libfoo.so files
>>> c) the include directories (assuming neither plasma5 nor kde-workspace
>>> were put in an explicit subdir)
>>>
>>> So, to get the first collision out of the way kde-workspace needs a
>>> flag to not build or install those bits (i.e. build in a library
>>> compatibility mode).
>>>
>>> The latter two could be addressed by renaming the libraries in plasma5
>>> to libkworkspace5.so etc. and respective include directory names. What
>>> I am not sure about here is whether there are more suitable
>>> distro-level solutions to this. Surely libfoo.so (libfoo.so.0) and
>>> libfoo.so (libfoo.so.1) conflicting cannot be a new issue, so I do
>>> wonder how this would be resolved in general.
>>>
>>> HS
>>
>> I'm very interested in renaming libkworkspace in Plasma5 at a minimum.
>> What do you suggest for the include directory - just kworkspace ->
>> kworkspace5 or go further and make the whole thing KF5Workspace?
>>
>> I'm happy to provide patches, but didn't so far since there was
>> resistance to the idea last time it was brought up.
> 
> Personally I'm very reluctant to the idea of changing the includes. The risk 
> of us having to hunt down breakage for weeks is IMHO way too high for the 
> possible benefits. We just had it too often during the  frameworks transition 
> that a header file got renamed, missed in one place and it starts to randomly 
> break to compile on some systems because a kde4 header is picked. Then we 
> easily waste huge amounts of work power on people trying to fix their build. 
> That's also the reason why I decided against renaming the headers for KWin.

That's fair enough, although I note the comparatively low number of
consumers would limit the scope for breakage.

I personally think it's worth the effort (and am willing to do the work)
for certain items because, for example, I can't offer our users the
ability to run KDE 4-based applications that depend on libkworkspace in
a Plasma 5 environment. It would be nice if we could, but if we can't,
we can't.