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