On Thu, Jul 10, 2014 at 5:40 PM, Michael Palimaka <kensing...@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
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
