4.x transition blockage - workspace libs

[Aleix Pol]

On Thu, Jul 10, 2014 at 5:40 PM, Michael Palimaka <kensington at gentoo.org>
wrote:

> 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.
>
>
KGet is not a core application. At least it was not part of the KDE
Workspace.

And as I said, KDevelop will still work, it just has to be compiled without
using libprocessui.

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