-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/118512/#review59409
-----------------------------------------------------------


I think you'll have to argue this out with vishesh, on discussing it with him 
he was happy for the libraries to be co-installable but didn't see a need for 
the development files to be co-installable.  Same for Baloo, only libraries 
with new sonames, otherwise it's a new version of everything.



- Jonathan Riddell


On June 4, 2014, 6:28 a.m., Matthew Dawson wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/118512/
> -----------------------------------------------------------
> 
> (Updated June 4, 2014, 6:28 a.m.)
> 
> 
> Review request for Plasma, Jonathan Riddell and Vishesh Handa.
> 
> 
> Bugs: https://bugs.gentoo.org/show_bug.cgi?id=512334
>     
> http://bugs.kde.org/show_bug.cgi?id=https://bugs.gentoo.org/show_bug.cgi?id=512334
> 
> 
> Repository: kfilemetadata
> 
> 
> Description
> -------
> 
> I've posted this RR as an RFC about the general structure of this idea.  I 
> just choose KFileMetaData as that is what my package manager conflicted over 
> first.  Ideally I want to push this change to any needed repositories for 
> Plasma Next.
> 
> As far as I understand the ability for Plasma Next and KDE4 application to be 
> co-installed, all libraries should be co-installable except as listed on this 
> page: http://community.kde.org/Plasma/Coinstallability .  However, on source 
> based distributions, such as Gentoo, to have both the KDE4 and KF5 versions 
> simultaneously installed requires that the development files are also 
> co-installable.  As mentioned on this Gentoo bug[1], the header files are 
> trivially dealt with, and the library simlink will probably be a downstream 
> specific solution (as CMake doesn't require it for compiling).  However, the 
> CMake configuration files are another matter.  This is take one of trying to 
> fix this issue.  If a different naming scheme, or if some different CMake 
> trickery is desired I'll see about changing things to that, otherwise I think 
> this is the simple and easy solution.
> 
> I also volunteer to go through all the dependent packages and have patches 
> ready (as best as I am able), as well as fix up any build failures that occur 
> due to this change.  Only find_package calls need modification, targets are 
> left alone.
> 
> [1] https://bugs.gentoo.org/show_bug.cgi?id=512334
> 
> 
> Diffs
> -----
> 
>   src/CMakeLists.txt 82dbd5c32050081642e9fff958d229f55893d40c 
>   KFileMetaDataConfig.cmake.in b4d1c93b7a23ffcbb03a89e9d4a11559d7e22037 
>   CMakeLists.txt aa2b0864ca8b2126ffcabf5cbad28b06dbb682b2 
> 
> Diff: https://git.reviewboard.kde.org/r/118512/diff/
> 
> 
> Testing
> -------
> 
> Tested compiling Baloo against a system install with this patch applied.  
> Baloo sucessfully linked against the KF5 version and all Baloo tests ran to 
> completion.
> 
> All KFileMetaData unit tests passed too ;)
> 
> 
> Thanks,
> 
> Matthew Dawson
> 
>

_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Reply via email to