Plasma search and one other

[Duncan]

René J.V. Bertin posted on Wed, 22 Mar 2017 16:40:34 +0100 as excerpted:

> On Wednesday March 22 2017 14:58:01 John wrote:
>>I didn't realise that this was running but noticed it with all of the
>>options selected in kdesettings-search so unchecked all. Done I thought
>>except when I looked again after a reboot which meant logging in again
>>and all were active. This seems to be caused by just logging out of the
>>desktop and back in again. Tried it several times and it always happens
>>- deselect all and log back in and they are all active again. I did
>>click apply when I deselected.
> 
> If you really don't want indexing because you never intend to use the
> search feature built upon it (something I could understand) your best
> bet is to uninstall the components that irk you most. One way would be
> to check what executable is hogging the CPU and/or disk while indexing,
> look up the corresponding package and uninstall that. With some luck
> your distribution allows you to do that without uninstalling all kinds
> of things you do want to keep.
> 
> If you're building from source you can just delete the culprit.
> 
> FWIW, KF5 5.26.0 is quite old by now, and you're probably using a Plasma
> version that's equally old. I think Plasma has evolved more since "that
> time" than the frameworks have so it's very likely that a lot of your
> gripes have been addressed in the meantime.

Note that until quite recently, plasma "required" baloo (the indexing 
daemon) at build-time, failing configure with a baloo-not-found error if 
it was missing.  The two specific packages requiring it were plasma-
desktop and plasma-workspace, because they have a handful of plasmoids/
run-dialog-search-plugins that use it.

So it couldn't be uninstalled, at least as shipped by kde/plasma upstream.

Unfortunately, the baloo build files triggered cmake bugs[1] with certain 
cmake versions and the installation layout I have locally, so rebuilding 
it was always a hassle as I'd have to downgrade cmake to something that 
actually worked every time.  That for a package I didn't want installed 
in the first place as I had no use for it other than those build-time 
deps, making the problem even /more/ frustrating!

However, note that "required" is in quotes.  There's a reason for that.  
Fortunately, modern plasma is reasonably modular, the modules in question 
were in their own subdir with nothing but the cmake-based build 
instructions depending on them, and the cmake and subdirs files were easy 
enough to read and create a patch that commented out the find-baloo test 
in the cmake files along with the baloo subdirs in the subdirs file.

So eventually I patched it out locally, and filed a gentoo bug asking 
them to make it USE-flag-optional as they did in kde4.  The gentoo devs 
asked me to make a proper patch to make baloo optional (as it was in kde4) 
and submit it upstream, closing the bug as "resolved/upstream".  
Unfortunately I'm not a dev, just a sysadmin who was doing what I had to 
do to keep things working properly locally, and I don't know cmake well 
enough to submit a proper patch, either to fix the cmake bug or to make 
baloo optional.

Fortunately, baloo has other bugs, including serious breakage in 32-bit 
x86 (segfault when the index file gets over 2 GiB, IIRC, used to be a 
common problem on x86, still is in baloo, as it has been basically 
maintainerless for some time and nobody has bothered figuring out and 
testing a patch properly), so at some point when that came up in a 
discussion, the gentoo/kde devs took the opportunity to suggest making 
baloo an option in plasma5 as it was in plasma4.  The gentoo/kde devs 
notified me via the bug I had filed, and I was able to follow the 
discussion.

After some discussion, the plasma devs decided making baloo optional was 
a good idea, even if one of them in particular would normally have been 
in favor of keeping it mandatory.  With baloo broken if its index got too 
big and its segfaults making plasma look bad on x86 anyway, without a 
proper maintainer so even if that was fixed there'd be other bugs, and 
based on the argument that some distros and users were going to try to 
patch it out anyway and might introduce other bugs if they did it wrong, 
the decision was made to ship it with the option there, but recommended 
on and default-enabled.

But it finally was an official option again, so gentoo/kde could make it 
a proper USE flag again, and I could drop my monkey-patches. =:^)

But as I said, that's fairly recent.  Since I'm running live-git, I tend 
to lose track of versioning and can't tell you exactly when the option 
was introduced, but it's there now, even if somewhat recent.

Meanwhile, most binary-based distros will of course continue to ship with 
the build-time baloo option enabled, meaning they build against it, and 
are very unlikely to support actually uninstalling it.

But at least the official no-baloo option is there for those who build 
from sources, for those source-based distros like gentoo that choose to 
expose it, for the few binary-based "lite" distros that will turn it off 
as shipped, and for individual users who build their own, without direct 
distro support. =:^)

Unfortunately, AFAIK kdepim based packages still require akonadi and 
think baloo or some other semantic-desktop junk too.  But I'm no longer 
keeping track of exactly what, as I long since killed anything kdepim 
related when kmail, asked to do a simple task of managing mail that mail 
apps have been doing for decades now, couldn't manage to do it without 
repeated crashes and losing mail after it went akonadi-based.  Yeah, I 
could /usually/ get it back if I jumped thru the correct hoops, but after 
many decades of reliable mail clients they're NOT rocket science, and 
repeatedly losing mail is simply unacceptable in the modern world.  So I 
did /not/ accept it, instead moving to something that actually worked.

Ironically, what I moved on to was claws-mail, the same claws-mail that 
originated as sylpheed-claws, the same sylpheed-claws that I tried and 
then left for kmail, back around the turn of the century when I was 
switching from Outlook Express on MS, when MS pushed me off their 
products due to eXPrivacy.  Had I chosen sylpheed-claws back then, I'd 
have never had the pain of having to switch off of kmail nearly a decade 
later.

Bottom line, uninstalling baloo and related components is likely not a 
(supported) option on most binary distros or if the plasma5's old 
enough.  Building yourself may be required, and with old plasma5s, 
patching as well, due to upstream lacking the build-time option.

But the good news is it *is* actually possible, for plasma at least.  I 
don't believe it's possible if the user is using (frameworks5-based) 
kmail, or likely, much of anything else kdepim-related.

---
[1] Cmake bugs: I have a "reverse-merged" /usr installation, along with 
the bin/sbin merge, here.  While most distros that do /usr unification 
make /bin and /lib(64) symlinks to /usr/bin and /usr/lib(64) 
respectively, so the /usr locations are canonical, as any respectable 
sysadmin I thought those four extra chars of typing were ridiculous and 
chose to reverse that, so I actually made /usr the symlink: /usr -> . , 
which of course puts everything that would go to /usr in / itself, 
effectively omitting the usr/ segment and making the / locations 
canonical.  That's the reverse-usr-merge bit.  Additionally, all my sbin 
dirs symlink to the bin location, which means /bin for /usr/sbin, since 
as explained above my /usr -> .  That's the bin/sbin merge bit.  Finally, 
as most gentoo/amd64 users, my lib and lib64 are merged, here with /lib 
being a symlink to lib64, making /usr/lib and /usr/lib64 both actually 
point to /lib64 due to the reverse-usr-merge.

Some versions of cmake have problems following all those symlinks at 
least as the baloo cmake build was setup and would trigger baloo build 
failures, but ONLY baloo build failures, not anything else kde related, 
which is weird as pretty much all of kde/frameworks/plasma/apps5 is cmake-
based.  So I'd have to install a known-working version of cmake any time 
I wanted to rebuild baloo.

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