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

[Ralf Habacker]

David Faure schrieb:
> On Monday 07 April 2008, Ralf Habacker wrote:
>   
>> David Faure schrieb:
>>     
>>> On Friday 04 April 2008, Ralf Habacker wrote:
>>>   
>>>       
>>>> Hi,
>>>>
>>>> appended is a patch for kbuildsycoca which checks a changed home and/or
>>>> install directory and triggers a complete recreate of the ksycoca
>>>> database in those cases. This is required for usb stick installations.
>>>>
>>>> The patch is currently limited to windows, although it may also be
>>>> usefull for unix os. In that case i would remove the conditionals.
>>>>     
>>>>         
>>> Yes this would be most useful, on unix too, please commit without ifdefs.
>>>
>>>
>>> In fact it makes me think again about my idea of having one ksycoca per value of kfsstnd_prefixes,
>>> and a config file (ksycocarc?) to do the mapping...
>>>
>>> ... pasting from my 27/03/2006 email: ...
>>>
>>> [/opt/kde3]
>>> FileName=ksycoca1
>>> [/d/kde/inst/kofficedir:/d/kde/inst/kde3]
>>> FileName=ksycoca2
>>>
>>> This way, for a given value of KDEDIRS, the code can easily lookup the ksycoca to
>>> use, and two sessions of KDE with different parameters will stop overwriting
>>> each other's ksycoca.
>>>
>>> ... end paste...
>>>
>>> Of course this is all "for a given value of $KDEHOME". When using another kdehome you end
>>> up with another ksycocarc, just like right now you end up with a different ksycoca.
>>>
>>> This is happening to me right now with kdelibs-4.0 and kdelibs-trunk on the same computer,
>>> and even though I don't run both as a user, the unit tests from both use KDEHOME=~/.kde-unit-test
>>> so I have to remove the ksycoca db by hand if I don't want mixups happening...
>>>
>>> What do you think about my proposed solution?
>>>   
>>>       
>> As you said - this is a request/proposal for a 
>> multi-ksycoca-database-handling in a single-user-environment which the 
>> windows developers are faced too, for example when having a release 
>> build and a debug build in different pathes under the same windows user.
>>     
>
> Right.
>
>   
>> Using different ksycoca databases will add extra complexitivity to 
>> building, maintaing and accessing those files (iterating over entries of 
>> more than one data streams), may add extra delay on application startup 
>> loading all those ksycoca's - I'm not sure if the required effort would 
>> be worth. 
>>     
>
> Wait wait -- I never said that an app would load more than one ksycoca, this would make no sense.
> If an app is started with a given value of $KDEDIRS, it would get that associated ksycoca. Just that one.
>   
okay
>   
>> Additional using hard coded paths in a ksycocarc file would  
>> add headache in maintaining this files - on windows this would not be a 
>> reliable solution.
>>     
>
> But it would be automatically generated, no user intervention needed.
> If you install stuff somewhere else, you get a new entry in your ksycocarc, when
> kbuildsycoca notices that it's not there already...
>
>   
>> At least on windows it would be enough to add kde installation path to 
>> the ksyscoca database name to have unique databases for each 
>> installation for the same user.
>>     
>
> Well that's exactly my idea, except that instead of putting the full value of $KDEDIRS
> into the filename itself (which could become HUGE!), I'm making that association in a config file.
>   
[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 ?
>   
>> Unfortunally there are two problems:
>>
>> - the ksycoca path is generated in two places - one in bool 
>> kdecore/ksycoca/ksycoca.cpp KSycocaPrivate::openDatabase( bool 
>> openDummyIfNotFound ) and one in kded/kbuildsycoca.cpp  in static 
>> QString sycocaPath(). At first it is required to move this to a common 
>> place - my suggestion would be a static method of class KSycoca say 
>> QString KSycoca::absoluteFilePath() which can be used by both places - 
>> Appended is a related patch for reviewing.
>>     
>
> Yes this is obviously OK.
> But this should use an enum instead of a bool.
>   
you mean something like

class KSycoca  {
...
public:
    typedef enum { localDatabase, globalDatabase } DatabaseType;

   QString absoluteFilePath(DatabaseType type=localDatabase);
....
}
>> - I have not found any QString KStandardDirs::installPath(const char 
>> *type) with type "root" to get the install path or do i have missed 
>> something ?
>>     
>
> This would defeat the whole idea of KStandardDirs.
> We don't want people calling that and then appending e.g. "share/kde4/services",
> we want them to call locate("services"). This is so that distributors can install
> services whereever they want (or any other directory controlled by KStandardDirs).
>   
I understand
> also, there isn't just "one install path", there is a list of paths, for enterprise setups
> with group setup -- hence $KDEDIRS.
> Don't you simply want KGlobal::dirs()->kfsstnd_prefixes()?
>   
you're right, this would be the correct value
> 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.

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

 - otherwise see [1]

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

just my 2 cent

Ralf