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
