kbuildsycoca global in a modern world

[Harald Sitter]

On Sun, Jul 21, 2019 at 5:38 PM David Faure <faure at kde.org> wrote:
>
> 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 :-)

Right, so I am very much in favor of removing this feature. It seems
entirely unlikely it is being used given the current state it was in.
And ultimately the same effect can be achieved by generating a ksycoca
and then copying into /etc/skel or some other place so it gets picked
up by the session. We really don't need special code for a kiosk use
case.

HS