[gentoo-desktop] Re: FWIW, kde-plasma/plasma-desktop and kde-plasma/plasma-workspace no-baloo enhancement bug and patches

[Duncan]

Michael Palimaka posted on Sun, 03 Apr 2016 04:05:13 +1000 as excerpted:

[snippy-snip]

> If I understand correctly, at least part of the Plasma team does not
> view optional dependencies as something that should be toggled lightly.
> Rather, they would prefer they are always enabled unless being built on
> a platform where that dependency doesn't make sense.
>
> While I am too personally in favour of as much being optional as
> possible, I certainly appreciate their view - more options means more
> complex code, more codepaths and more possibility for breakage. It's
> been found in the past that many packages with optional dependencies
> failed to build when those optional dependencies were missing, simply
> because nobody has that configuration to test with.

Of course this is one reason why even much of the FLOSS world considers 
gentooers insane.

Of course we have our reasons, but equally importantly, viewed from a 
different angle, "exercising" those optional dependencies is valuable, 
for much the same reason attempting to build with llvm and friends, even 
if you don't recommend it for production use and default to gcc, is 
valuable.  Similarly, building on all those exotic archs.  In each case, 
while the benefit is arguably limited and may not in itself be worth the 
hassle, in the end it finds bugs, and patching them makes for a much 
stronger product all around, including when built with all recommended 
deps, with the default toolchain, on the most mainstream arch and OS of 
them all (generally considered to be 64-bit x86 for gnu/linux, these 
days, tho arguably only because the arm processors android/linux is 
normally deployed on are far more varied than x86, or they'd certainly 
take that crown)

> As such, I doubt upstream will be interesting in making such a major
> feature as Baloo optional at build time.

As long as they keep it modular enough to continue hard-disabling via 
patch, where desired, without seriously increasing the complexity of the 
process.  At this level on kde/frameworks/plasma5 it's a couple simple 
patches, but I doubt gentoo would have tried it with the far more complex 
and less modular kde4 if it hadn't been supported upstream, in which case 
I wouldn't have had anything to continue to base patches on during the 
period when gentoo/kde quit supporting it on kde4, and I *KNOW* it was 
/way/ beyond my skills without being able to lean on gentoo's patches, 
back on kde4.

But at least for the time being it's extremely simple for kde/frameworks/
plasma5, and as long as it stays that way, not a problem.

If it ever gets out of hand, well, I've always said that one way or 
another, the file indexer isn't going to be running long on my desktop 
(temporarily exception for porting and working out all the deps allowed 
and taken).  As long as I can arrange to kill the deps in kde, I'll 
likely keep the kde desktop.  If that becomes no longer possible, there's 
a very good chance, I'd say 80% or better, I'll be off of kde entirely 
within a year.  Back before the turn of the century I was running MS 
betas and was inline at midnight for MS Windows 98.  Then the eXPrivacy 
malware crossed a line I wouldn't cross, and I became nearly as 
proficient on Linux in three months as I had done on MS in nearly a 
decade.

Similarly, back in the kde3 era I was very nearly fully standardized on 
kde, wondering if I could switch a couple more apps and avoid gtk on my 
system at all.  During the fiasco that was the switch to kde4 I switched 
to non-kde for some of it, and switched even more when they broke kmail 
with akonadi, and when a couple potential security issues in konqueror 
went unfixed for way too long, and it became apparent they were treating 
it more like a toy than something serious that people could properly do 
their banking and etc on.  They even broke global hotkey chaining in kde4, 
so I had to switch my hotkey setup to something else, and thus didn't 
really have to worry about it in the kde5 upgrade (except for kde hotkeys 
themselves, kwin-based zoom, invoking the cube, etc, session logout, kmix 
hotkeys, etc, but if I dump plasma those go with it and I configure 
whatever I replace plasma and kwin with, with my hotkeys).

So now, other than the desktop itself, some kdegames, gwenview, and 
superkaramba, I'm pretty much off of kde, which is why it's relatively 
easy to run the live-9999 testing version of the parts of kde I do have 
installed.  And of course superkaramba is now a dead package upstream, so 
while it's working for now, I'll have to find a replacement for it within 
a year or so.  I already have a replacement for gwenview, that I used 
when gwenview was broken for me for a time.  And the games I can either 
do without, find replacements for, or install individually.  Which means 
it's pretty much only the desktop.

So as I said, if at some point they interweave baloo into the desktop to 
the point I can't unweave it, I'll probably be off it too, within a year 
and most likely within 2-4 months.

> In addition to sticking to upstream, I note it's easy to turn off at
> runtime if unwanted and baloo:5 has a much lighter deptree than baloo:4.

That is /definitely/ true. =:^)

But of course it doesn't help when baloo isn't building with current 
cmake.  I had a bug on that (as I expect you're aware but others here may 
not be), but it turned out that was simply more motivation to figure out 
how to kill baloo, given that several cmake upgrades over some months 
hadn't fixed it, so it looked like I was either going to have to 
seriously dig into it myself or dig into figuring out how to kill that 
dep, which was my ultimate goal anyway, so when I had the time to spend, 
it's obvious where I spent it.


But truth be told, if there wasn't so much bad water under the bridge 
with the still horribly broken semantic-desktop crammed down our throats 
in the kde4 era, with it being easier to fully disable at runtime in kde/
plasma5, I'd have 90% chance been satisfied with just that, and would 
have been far more likely to jump thru the hoops the other way with the 
baloo building bug, tracing it down instead of making it my job to figure 
out how to exterminate baloo, even if I do find it worse than useless 
when actually running (since I find very nearly useless, it's very nearly 
worthless to me, even were it able to run at zero resource cost, but of 
course it's not zero resource cost, in either CPU time or indexing space, 
so the already nearly worthless actually ends up well into the negative).

> Even though we weren't able to integrate your changes, thanks for your
> work. It's interesting to know how simple it actually is and I'm sure
> there's others who will find it useful too.

Thanks.  Like I said, getting it out there for anyone else that found it 
useful in the absence of gentoo/kde taking it, was at least as important 
to me as getting an answer one way or the other on whether gentoo/kde 
/would/ take it, particularly since I figured I pretty much knew the 
answer to the latter already.  Tho it never hurts to ask, particularly 
when there's further reasons for posting as well. =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman