Review Request 128956: Make KF5Baloo optional

[Andreas Sturmlechner]

> On Sept. 20, 2016, 12:10 p.m., David Edmundson wrote:
> > >Usage of krunner without any segfaults.
> > 
> > You can just disable it with the provided checkbox, you don't gain anything from disabling it at compile time.
> 
> Andreas Sturmlechner wrote:
>     That's not quite true; even with runtime-disabled baloo there have been segfaults (due to the fact there was no db).
> 
> David Edmundson wrote:
>     Not if you disable the search plugins in krunner.
> 
> Andreas Sturmlechner wrote:
>     That should probably be tied to the KCM checkbox as well - you wouldn't expect having to disable it in two places. Regardless, this is all happening after login when baloo is already doing its indexing first-run - and we know that the KCM checkbox does not stop the ongoing indexing.
>     
>     Providing it as an option at build time does not mean you are less committed to Baloo as a whole. But it makes it possible to disable it based on architecture (you may argue with the 1GB-segfault-limit it is broken enough on 32 bit) or choice (using a different indexing mechanism).
> 
> Anthony Fieroni wrote:
>     I think you can provide backtrace for issue to be resolved, since to disable plugin in compile time.
> 
> Andreas Sturmlechner wrote:
>     I could provide a few nice quotes there, but really, the relevant discussion is linked in the description above. Basically, Plasma-5 currently hard-depends on a Framework that is (knowingly!) broken on 32 bit and has no maintainer. Even though given that, it is not the core reason for trying to make it optional.
> 
> David Edmundson wrote:
>     To some extent I agree with you,  there is no extra burden for us and the current CMake is wrong anwyay.
>     
>     But I don't think you've stated what your core reason for making it optional actually is.

The core reason for me is a pragmatic view on the build system, especially in a big repository: Imo it is a nice place to indicate what is possible. If you insist that every component is required - most of them will be - and leave it to binary packaging, people will do their thing anyway and possibly do it wrong, at which point it may come back at you later in bugzilla. In this case it will mostly get us rid of baloo and its dependencies, even if they are not that big, but e.g. to someone preparing systems with /home over NFS it signals that no bad things will happen for having a feature disabled that simply will not work there nor make sense.


- Andreas


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


On Sept. 20, 2016, 12:06 p.m., Andreas Sturmlechner wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128956/
> -----------------------------------------------------------
> 
> (Updated Sept. 20, 2016, 12:06 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> -------
> 
> https://mail.kde.org/pipermail/kde-frameworks-devel/2016-September/037734.html
> 
> Regardless of the current state of Baloo, it is not very deeply tied into Plasma. Usage in plasma-workspace comes down to providing the baloo runner.
> 
> 
> Diffs
> -----
> 
>   CMakeLists.txt 9da918358bd797b8fe00de646b6576ba22976d0e 
>   runners/CMakeLists.txt 48cc3799f834a57031ae387a35f41859178fe317 
> 
> Diff: https://git.reviewboard.kde.org/r/128956/diff/
> 
> 
> Testing
> -------
> 
> Several days of Plasma-5 without any issues. Usage of krunner without any segfaults.
> 
> 
> Thanks,
> 
> Andreas Sturmlechner
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20161009/65dd1b53/attachment-0001.html>