On Wed, Jul 9, 2014 at 4:32 PM, Harald Sitter <sit...@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
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
