<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jul 9, 2014 at 4:32 PM, Harald Sitter <span dir="ltr"><<a href="mailto:sitter@kde.org" target="_blank">sitter@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

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

<div><br></div><div>For example, I introduced the libprocessui dependency in KDevelop and I knew this was bound to happen when I implemented this ~5 years ago.</div><div><br></div><div>Aleix</div></div></div></div>