[kde-freebsd] RFC kde frameworks/plasma 5 import

[Max Brazhnikov]

On Thu, 09 Apr 2015 12:54:51 +0200 Tobias Berner wrote:
> Hi there
> 
> I would like to import my kde5 stuff into an area51 branch soon...
> [provided you are ok with that]
> 
> 
> I have a few questions first though:
> 
> 1) Would it be possible to rename some ports from the kde4- prefix to just a simple kde- prefix?

The kde4 prefixes were added to distinguish the ports from their KDE 3 counterparts. Now they can be omitted.

>    For example x11-themes/kde4-icons-oxygen and x11/kde4-baseapps.
>    The reason being that icons-oxygen is needed by both -- and the name thus would be misleading, 
>    and baseapps can be used by both "desktop"-versions (and plasma5 is really empty without it).
>    [They're both part of kde-applications most of which probably will be ported to kf5 as time 
>    goes on anyways].
>    A similar candidate would be graphics/gwenview-kde4. The new version of applications 14.* 
>    links against frameworks. Should this port just be renamed to gwenview, or should the newer 
>    one be named gwenview-kde5?

Please avoid to use kde5 in any form (portsnames, options, etc). There are KDE Frameworks, Plasma, and Applications with their own versioning scheme and release schedule. I suggest to use kf5- prefix for framework ports, and appname (or kde-appname to avoid ambiguity) for applications.

> 
> 2) Is there a reason not to add something like
>       -DINCLUDE_INSTALL_DIR:PATH="${KDE4_PREFIX}/include/kdelibs"
>    to x11/kdelibs4/Makefile. So that its headers are no longer just in ${KDE4_PREFIX}/include 
>    by default?
>    The problem at the moment is, that for example kmessagebox.h is provided by 
> 	* kdelibs4 and residing in ${KDE4_PREFIX}/include
> 	* kde5-kwidgetsaddons residing in ${KDE4_PREFIX}/include/KF5/KWidgetsAddons
>    and the first one of them does get picked up wrongly when compiling some kde5 stuff. 
>    This can/could be avoided by just prefixing all kde4-headers 
>    (and this would also clean up ${KDE4_PREFIX}/include...)

This could be done in principle, but all ports that depends on kdelibs4 have to be tested and fixed if needed. We can request exp-run to find failing ports.
Btw, I think it's time to drop KDE_PREFIX, LOCALBASE should be used for kf5 ports.

> 3) There are some conflicting files when installing both kde4 and kde5-parts. For example
> 	* sysutils/balooo
> 	* sysutils/kde5-baloo
>    both provide bin/baloo*. 
>    I was thinking of adding something akin to
> 	# plasma5 needs applications using kdelibs4. But it provides certain binaries on
> 	# its own, eg bin/baloo. Only install those if the user does not care for kde5.
> 	# For kde5 users they are already provided by the newer ports
> 	OPTIONS_SINGLE= KDEDESKTOP
> 	OPTIONS_SINGLE_KDEDESKTOP=KDE4 KDE5
> 	KDE4_DESC=      You do NOT intend to install/run plasma5
> 	KDE5_DESC=      You intend to run plasma5
> 	# probably add also: KDE5_USE=       KDE5=baloo5_run
> 	OPTIONS_DEFAULT=KDE5
> 	OPTIONS_SUB=    yes
>    into sysutils/baloo/Makefile (and of course pkg-plist).  
>    [The reason I set default to KDE5 is that the newest kate, gwenview and konsole already are
>    KF5 applications]
>    Or how should this be handled? 

If baloo is a runtime dependency, then simply don't put in the port, but let user install whatever they want. If it is a build/lib dependency, then splitting the conflicting parts to separate ports is the only way to avoid conflict.

Max