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
_______________________________________________
kde-freebsd mailing list
kde-freebsd@kde.org
https://mail.kde.org/mailman/listinfo/kde-freebsd
See also http://freebsd.kde.org/ for latest information
