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

[Tobias Berner]

Thanks for the hints. 

> 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.
I renamed the frameworks ports to kf5-* and the plasma ones to plasma5-*. Would you also change USE_KDE5 (analouge to USE_KDE4) and split it into two, for example USE_KDE_FRAMEWORKS and USE_KDE_PLASMA to enforce the difference?


mfg Tobias





On Thursday 16. April 2015 11:35:55 Max Brazhnikov wrote:
> 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?
> 

> 
> > 
> > 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