4.x transition blockage - workspace libs

[Michael Palimaka]

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).

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.