4.x transition blockage - workspace libs

[Harald Sitter]

On Thu, Jul 10, 2014 at 5:40 PM, Michael Palimaka <kensington at gentoo.org> wrote:
> On 07/10/2014 12:32 AM, Harald Sitter wrote:
>> Ahoy everyone,
>>
>> I recently got into a discussion about the 5.0 workspace transition
>> and how this can be kept from having impact on 4.x applications in any
>> form. Having looked into this I have to say that there are problems...
>>
>> The mail is a bit on the long side, so please bear with me. It's important :)
>>
>> The primary problem is that the release blob we call(ed) kde-workspace
>> contained libraries, in particularly libraries that were freely
>> linkable from the outside and exactly that is what happened.
>>
>> Research on all kdelibs4 based software in Kubuntu shows that
>> specifically two libraries are used by the outside:
>>
>> - libprocessui4 (used by kdevelop and sentinella) [additionally
>> requires libprocesscore4]
>> - libkworkspace4 (used by kget, ktorrent, ktux and apper)
>>
>> In order to build/run the mentioned applications one needs to have
>> kde-workspace built and installed which then conflicts with
>> plasma-workspace being built and installed. This directly contradicts
>> the promise of a smooth workspace transition as one cannot have
>> kde-workspace and plasma5 installed at the same time, so in theory one
>> cannot use these existing applications without either manually messing
>> with kde-workspace or the applications.
>>
>> ## What to do?
>>
>> The good news is that from looking at the libraries I believe at least
>> the ones I can identify as being used outside workspace are perfectly
>> usable on their own without any of the additional kde-workspace bits,
>> which makes it a lot easier for us to provide a solution.
>>
>> Namely we need a cmake switch in kde-workspace (4.11.whatever) to make
>> it build/install a plasma5 compatible subset of binary artifacts (i.e.
>> the libraries I mentioned). In addition to that I think it would also
>> be wise to rename the include directories on the plasma5 end to avoid
>> conflicts now and in the future.
>>
>> ## Impact
>>
>> This problem hits every distribution that can only or wants to
>> distribute binary packages in line with how we distribute source
>> packages. Meaning for 4.x kde-workspace is one binary package, and
>> kde-runtime is one binary package etc. etc.
>> Notible examples are Gentoo and Slackware.
>>
>> Additionally please do note that since the libraries are public any
>> third party may have used them, unless other distros do some checks we
>> can do nothing but hope that it's really only libprocess* and
>> libkworkspace that are affected.
>>
>> ## Moving forward
>>
>> I think a careful look at which library we want to be usable by third
>> parties is long overdue. Then clearly mark all others in a way that
>> makes it obvious that we do not support them outside our own use (e.g.
>> call them libkittenprivate or something). Otherwise we hit very
>> similar nonesense come 6.0.
>>
>>
>> Any thoughts on this? Any volunteers? Any objections? Any better ideas?
>>
>> HS
>>
>
> It's probably a bit late now, but we could just rename the offending
> libraries in Plasma 5 (as has already been done with some).

Since the libs aren't supposed to be used outside the workspace it
doesn't really matter if we rename them I think. This would also be
achived by giving them sensible names such as libkworkspaceprivate.so
to make it clear that people shouldn't use the libs ;)

> Regardless of whether the libraries should have been used originally or
> not, it's really not a good situation when we can't run core KDE
> applications like kget or popular non-core applications like kdevelop in
> Plasma 5.

FWIW, kget (kdenetwork), ktorrent and apper (exptragear) could
actually be ported away from kworkspace entirely. They respectively
use it to implement their shutdown-when-download-done feature. This
could just as well (and IMHO should) be done via ksmserver's dbus
interface as of course it is considerably more portable (at the same
time it also is less explicit, so there's that). Also I just checked
all three and in the case of kget and ktorrent the feature appears to
be entirely optional (just like with kdevelop) ... OTOH it is a pretty
standard feature for download things to have these days so I don't
think compiling without it is very reasonable ^^
apper has it as a required feature unfortunately.

ktux (kdetoys) is an entirely different story:
> message( STATUS "Ktux can't be compiled. Install kdebase/workspace before" )

So not only do third parties not know they shouldn't use workspace
libs, we (as in KDE) don't even know as is evident through apper and
ktux.... I really really really think we should appreciate the issue
and do something about it.

HS