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

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.
>=20
> 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=20
gentooers insane.

Of course we have our reasons, but equally importantly, viewed from a=20
different angle, "exercising" those optional dependencies is valuable,=20
for much the same reason attempting to build with llvm and friends, even=20
if you don't recommend it for production use and default to gcc, is=20
valuable.  Similarly, building on all those exotic archs.  In each case,=20
while the benefit is arguably limited and may not in itself be worth the=20
hassle, in the end it finds bugs, and patching them makes for a much=20
stronger product all around, including when built with all recommended=20
deps, with the default toolchain, on the most mainstream arch and OS of=20
them all (generally considered to be 64-bit x86 for gnu/linux, these=20
days, tho arguably only because the arm processors android/linux is=20
normally deployed on are far more varied than x86, or they'd certainly=20
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=20
patch, where desired, without seriously increasing the complexity of the=20
process.  At this level on kde/frameworks/plasma5 it's a couple simple=20
patches, but I doubt gentoo would have tried it with the far more complex=
=20
and less modular kde4 if it hadn't been supported upstream, in which case=
=20
I wouldn't have had anything to continue to base patches on during the=20
period when gentoo/kde quit supporting it on kde4, and I *KNOW* it was=20
/way/ beyond my skills without being able to lean on gentoo's patches,=20
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=20
another, the file indexer isn't going to be running long on my desktop=20
(temporarily exception for porting and working out all the deps allowed=20
and taken).  As long as I can arrange to kill the deps in kde, I'll=20
likely keep the kde desktop.  If that becomes no longer possible, there's=
=20
a very good chance, I'd say 80% or better, I'll be off of kde entirely=20
within a year.  Back before the turn of the century I was running MS=20
betas and was inline at midnight for MS Windows 98.  Then the eXPrivacy=20
malware crossed a line I wouldn't cross, and I became nearly as=20
proficient on Linux in three months as I had done on MS in nearly a=20
decade.

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

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

So as I said, if at some point they interweave baloo into the desktop to=20
the point I can't unweave it, I'll probably be off it too, within a year=20
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. =3D:^)

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


But truth be told, if there wasn't so much bad water under the bridge=20
with the still horribly broken semantic-desktop crammed down our throats=20
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=20
have been far more likely to jump thru the hoops the other way with the=20
baloo building bug, tracing it down instead of making it my job to figure=
=20
out how to exterminate baloo, even if I do find it worse than useless=20
when actually running (since I find very nearly useless, it's very nearly=
=20
worthless to me, even were it able to run at zero resource cost, but of=20
course it's not zero resource cost, in either CPU time or indexing space,=
=20
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=20
useful in the absence of gentoo/kde taking it, was at least as important=20
to me as getting an answer one way or the other on whether gentoo/kde=20
/would/ take it, particularly since I figured I pretty much knew the=20
answer to the latter already.  Tho it never hurts to ask, particularly=20
when there's further reasons for posting as well. =3D:^)

--=20
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