4.x transition blockage - workspace libs

Harald Sitter sitter at kde.org
Wed Jul 9 14:32:22 UTC 2014


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


More information about the Plasma-devel mailing list