<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Jul 10, 2014 at 5:40 PM, Michael Palimaka <span dir="ltr"><<a href="mailto:kensington@gentoo.org" target="_blank">kensington@gentoo.org</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 07/10/2014 12:32 AM, Harald Sitter wrote:<br>
> 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>
><br>
<br>
</div></div>It's probably a bit late now, but we could just rename the offending<br>
libraries in Plasma 5 (as has already been done with some).<br>
<br>
Regardless of whether the libraries should have been used originally or<br>
not, it's really not a good situation when we can't run core KDE<br>
applications like kget or popular non-core applications like kdevelop in<br>
Plasma 5.<br>
<div class="HOEnZb"><div class="h5"><br>
</div></div></blockquote></div><br></div><div class="gmail_extra">KGet is not a core application. At least it was not part of the KDE Workspace.</div><div class="gmail_extra"><br></div><div class="gmail_extra">And as I said, KDevelop will still work, it just has to be compiled without using libprocessui.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">Aleix</div></div>