4.x transition blockage - workspace libs

[Aleix Pol]

On Wed, Jul 9, 2014 at 4:32 PM, Harald Sitter <sitter at kde.org> 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
>

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.

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.

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

Aleix
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20140709/f81957d2/attachment.html>