Support for out of prefix installation
klingens at kde.org
Wed Feb 8 09:51:01 GMT 2006
On Wednesday 08 February 2006 01:19, Waldo Bastian wrote:
> There are two different ways to address the problem associated with out of
> prefix installation: the first one is to tell out-of-prefix applications to
> install certain resources within a designated prefix. (e.g. under
> /usr/share or /usr/local/share),
> the second one is to provide applications with a way to register their
> location with the "system" (e.g. applications can edit /etc/man.config to
> add additional locations for manual pages and could edit /etc/kderc to add
> additional KDE resource directories), effectively extending the set of
The second approach will kill the performance kbuildsycoca and other parts of
KDE quickly due to the vast amount of extra folders that need scanning and
thus the extra stat calls involved.
The first approach basically tells 3rd parties to still install files outside
their own realm, which is exactly what we want to avoid.
What about the following third option? Currently all KDE resource handling
(kbuildsycoca, KStandardDirs and all friends) look in several places that can
be roughly described as $KDEHOME + $KDEDIRS for simplicity (and in this order
as far as precedence goes).
Suppose we install a 3rd party app in $APPDIR, then for this application (and
*ONLY* for this application) the resources should be looked for in $KDEHOME,
$APPDIR, $KDEDIRS. If kbuildsycoca could create multiple sycocas (one for
$KDEHOME, one for $APPDIR and one for all shared lower-level dirs combined)
and merge them then we can keep the performance level up and also keep apps in
their own prefix. The existing full sycoca can (and probably should) be kept
for performance reasons for the apps that reside in $KDEDIR.
App startup would then roughly be as follows:
1. App checks whether its binary is part of $KDEDIRS
2a. If yes, load the sycoca as we know it now and be done.
2b. If no, check if there is a partial sycoca for $APPDIR, and create it if
it's missing. Next, load the partial sycocas for $KDEHOME and $KDEDIRS and
merge the three.
This would work with all application-specific resources including (but not
limited to) services and servicetypes, plugins, icons and xmlgui. The only
case where it does not work is for stuff that needs to interact with other
KDE apps (Konqueror service menus, mime type associations, K Menu
entries, ...), but those are special anyway, and having 3rd parties take
special measures for those is not a big deal. It can't be easily avoided, and
all other major desktops, including Gnome and Windows, have a similar setup
for making such resources show up properly.
More information about the kde-core-devel