automatic kbuildsycoca recreate when home dir and/or install dir changes

[David Faure]

On Tuesday 08 April 2008, Ralf Habacker wrote:
> [1]
> I understand that this ksycocarc contains the association - I do not 
> understand why this file is really required - would the same not be 
> possible by using a directly association by generating a hash code to 
> generate a part of the ksycoca filename ?

Yes this would work too. But it would be very opaque to the (power) user -- how do
I know which ksycoca file to delete if I have some problem somewhere?
OK for a debug build one can see the ksycoca path in the debug output...

> you mean something like
> 
> class KSycoca  {
> ...
> public:
>     typedef enum { localDatabase, globalDatabase } DatabaseType;
yes (titlecase, though: LocalDatabase, GlobalDatabase)

>    QString absoluteFilePath(DatabaseType type=localDatabase);
> ....
> }

> > The point is that the ksycoca for KDEDIRS=/d/kde/inst/koffice15dir:/d/kde/inst/kde3
> > is not the same as the ksycoca for KDEDIRS=/d/kde/inst/koffice16dir:/d/kde/inst/kde3
> > Hence my idea of ksycocarc for mapping from KDEDIRS to which ksycoca to use
> > (yes, which is equivalent functionally to naming it ksycoca_d_kde_inst_koffice16dir_separator_d_kde_inst_kde3 :)
> >   
> the clear text form has the advantage that it is obviously for what 
> those ksycoca is for which - when using a ksycocarc the association 
> could reverse looked up.

parse error in the 2nd part of the sentence, but I guess you mean that finding out
the kdedirs for this ksycoca file requires opening ksycocarc.

> BTW: There are additional places where (at least partial) pathes are 
> used in user related files for example 
> .kde\cache-BRAMSCHE\help\de____khelpcenter__faq__about.docbook

Yes, but KDEDIRS can be much bigger. It just seems dirty.

>  - otherwise see [1]

Let's try with a hash value for now, it's the solution that requires the least amount of code.
We can always change this later on if we don't like it - that's the good thing about ksycoca,
it's just a cache, so we can always delete it or "forget an old one and use a new filename in the future".

> What is left open is what you wrote already - how to delete obsolates 
> ksycoca files ? The real question is how should it be possible to 
> estimate if a given ksycoca will not be used in the future again ?

As I said, if the KDEDIRS associated with it don't exist anymore, then it's safe to delete it.
But if we only use a hash value in the name then we'll never delete files. However the number
of kde installations that a given user has can't be that big that this would be a real problem, I think.

> As far as i remember there is a timestamp in the ksycoca file - this 
> could probably be used by kbuildsycoca to detect outdated files, which 
> could be then deleted.

ksycoca is only touched when some .desktop file is modified. If an enterprise user (or even a kiosk-like machine)
runs the same version of KDE for a number of years, and never installs software or changes file associations,
ksycoca won't change during that time.
However if we make sure we don't delete the ksycoca for the running kde session (kbuildsycoca's own $KDEDIRS),
but only -other- ksycoca files, then no problem. Running multiple versions of KDE under one user is already
rare enough; having them running at the same time for years is even less likely.

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).