4.x transition blockage - workspace libs

[Bernd Steinhauser]

On 09/07/14 16:32, Harald Sitter wrote:
> - 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.

Hm, I wouldn't have thought that binary distros have these kind of issues.
However, you can resolve it at build time, by just building the libraries (and 
maybe some other parts that don't collide), which you can handle via the BUILD_* 
parameters generated by macro_optional_add_subdirectory.

The only parts which this does not work for are ksysguard, plasmagenericshell 
and plasmaclock in the libs subdir. Those you have to disable in the cmakes file.
That way, you can package a stripped-down package of kde-workspace containing
libkephal.so.4, libkworkspace.so.4, liboxygenstyle.so.4, 
liboxygenstyleconfig.so.4 and libtaskmanager.so.4 and libkscreensaver.so.5 (+ 
some other parts), which are helpful when using KDE4 apps on Plasma 5. Ensure 
that you don't ship the .so symlinks, since those would collide with Plasma 5 
(plasma-workspace mostly), but those are not necessary, since the cmake files 
ensure that applications are linked to .so.X.

The remaining binaries except startkde (which you have to remove) won't collide 
with Plasma 5.

> ## 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.
That's a good policy, but as a binary distro, in this case you just lose too 
much if you don't split it up. Given that splitting for a binary distro is much 
much easier than for a source-based one, I don't see the huge issue. A 
source-based distro on the other hand has the advantage of options (or use 
flags, how Gentoo calls them), which can handle these cases.

If you still don't want to split it on a binary distro, I would create a 
transitional package (i.e. kde-workspace-4-minimal), which contains the 
necessary parts.

> 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.
Actually, I think it's mainly liboxygenstyle that most people would want, at 
least if they got used to the nice style. ;)

Best Regards,
Bernd