kbuildsycoca global in a modern world

[David Faure]

On mardi 16 juillet 2019 13:08:02 CEST Harald Sitter wrote:
> I was wondering if kbuildsycoca's global code still has a reason to exist.

I wondered the same when I redesigned most of ksycoca some time ago,
and I chose to keep the feature.
The thinking is the following: imagine a kiosk-mode device where every login 
is a first time login for that user (because the user gets deleted every time, 
to start ). 
The startup will be slow every time because the ksycoca file has to be created 
by parsing all desktop files.
A sysadmin can run kbuildsycoca5 --global once and users will end up using 
that.
 
> The way I read the code a local kbuildsycoca would only reuse the
> global sycoca iff languages, prefixes and signatures are a match.

Same logic as for a local sycoca, yes.

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

Oops. That's a porting bug, I would say. The home dir shouldn't be taken into 
account for the global database.
I checked the kde4 code and it used to do
   if (bGlobalDatabase)
   {
     setenv("KDEHOME", "-", 1);
     setenv("KDEROOTHOME", "-", 1);
   }
exactly for this purpose.

WARNING WARNING the current code seems to not do that, and still it cleans up 
the local applications directory afterwards, so if you run 
kbuildsycoca5 --global in your user account, it will delete 
~/.local/share/applications, as far as I can see in the code!

I just removed that very dangerous cleanup code, don't try --global before
having that fix...
https://commits.kde.org/kservice/5cf75cedc26447bce4c1cf0b4c0fa71018f506f5

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

Right. As soon as you have things in XDG_DATA_HOME, you need a local ksycoca, 
that's for sure.
 
> Do we still need the global cache feature at all?

I wish Waldo Bastian was around to answer the following question: how does 
this feature differ from an autostart script copying a global ksycoca to the 
user's directory, in such a kiosk setup?

I can't see a good reason to keep the feature, actually :-)

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5