kbuildsycoca global in a modern world

Harald Sitter sitter at kde.org
Tue Jul 16 12:08:02 BST 2019


Hey!

I was wondering if kbuildsycoca's global code still has a reason to exist.

The way I read the code a local kbuildsycoca would only reuse the
global sycoca iff languages, prefixes and signatures are a match.
But prefixes are not ever the same in any "default" or even reasonable scenario.
Specifically, prefixes are essentially
QStandardPaths::GenericDataLocation paths and those include at least
one user-specific directory on every single platform documented for
QSP. On linuxy systems this is even a very important path as (e.g.)
application desktop files edited by kmenuedit are stored in
XDG_DATA_HOME, so not including that would break overrides or custom
software installs. Additionally bundle software such as flatpak can do
user-specific software installation which means it also injects paths
into XDG_DATA_DIRS.

So, as far as I can tell the prefix constraint is always false and
with that the global cache is not ever used. That leads me to the
questions:

Do we still need the global cache feature at all?

How would we even go about repairing this? We can't just ignore XDG_DATA_HOME.

Thoughts?

HS


More information about the Kde-frameworks-devel mailing list