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

[Schaich, Alonso]

On Thu, 09 Apr 2015 12:54:51 +0200
Tobias Berner <tcberner at gmail.com> wrote:

> Hi there
> 
> I would like to import my kde5 stuff into an area51 branch soon...
> [provided you are ok with that]

Area51 is a testing repository, so it's ok to commit "experimental"
ports there. Especially if you're on a branch.

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

It's possible to rename packages. You'll have to modify the MOVED file
in the CVS root though, for pkg to understand it's a renaming instead of
a deletion and an insertion of a different port.

Generally I think we should drop the kde version in pre- and suffices
from ports which aren't directly part of kde or not versioned by it, as
you are proposing. Further, kdevelop and konversation can probably drop
their kde suffices completely.

If gwenview and friends are updatable without breaking other installed
software, then there should be only one gwenview port used by both kde4
and kde5. gwenview and some other ports however install shared
libraries which are used by other software which eventually is not
maintained by kde@, such as libreoffice, or not in ports at all, and
this sofware might require either API compatibility (or in case it
can't be rebuilt, ABI compatibility), which AFAIK is not the case, or
support for KDE5 by the consumer ports.

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

You can add cmake args like those, eventually you'll have to patch some
FindXXX cmake scripts though in order for consumer ports to find the
headers/libs/data at the right paths. Alternatively you can have
KDE5_PREFIX be different from KDE4_PREFIX which should also solve the
issue.

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

>From your description, it sounds like I should install kde4-baloo if
I want to use *only* KDE4 and kde5-baloo otherwise. If that works, i.e.
if KDE4 can run with kde5-baloo, then just update baloo to its' KDE5
version. Otherwise it's preferable to be able to install both baloos at
the same time, e.g. for people who want to use kde5 apps in a kde4
desktop session.

> 
> 
> thanks in advance, and
> mfg Tobias


Note that I'm just stating my personal opinion, not any
area51/kde/ports guidelines, and you should probably wait for more
input from avilla, racuko, makc, or other longer term members who were
around at the transition from kde3 to kde4.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 603 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-freebsd/attachments/20150410/d0819292/attachment.sig>