Support for out of prefix installation

[Waldo Bastian]

KDE's resource handling (icons, menu items, help files, etc.) is based on the 
assumption that applications are installed in a fixed number of prefixes 
(e.g. /usr, /usr/local, /opt/kde3 depending on distribution).

Unfortunately this assumption isn't in line with the desire from end-users and 
third party developers to install applications elsewhere. The best known 
examples of this are autopackage and the LSB/FHS guideline to install 
applications entirely under /opt/<package>/

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 prefix'es.

The assumption here is that the application is installed as root.

Which approach would be better?

Cheers,
Waldo
-- 
Linux Client Architect - Channel Software Operation - Intel Corporation

----------  Forwarded Message  ----------

Subject: Re: Request for clarification on menu/file spec
Date: Tuesday 07 February 2006 15:56
From: Waldo Bastian <bastian at kde.org>
To: xdg at lists.freedesktop.org

On Tuesday 07 February 2006 10:59, Aaron J. Seigo wrote:
> On Tuesday 07 February 2006 11:17, Kevin Krammer wrote:
> > Maybe freedeskop.org should specify a file where the variables have to be
> > defined, something like /etc/xdg.conf
> >
> > Something like
> > "if environment variable XDG_DATA_DIRS is set, use the directories listed
> > there to look for file. If not set check /etc/xdg.conf. If not present
> > there either, assume defaults"
> >
> > That would allow to override normal settings by setting XDG_DATA_DIRS,
> > allow a central location for additions of the base environment and have
> > the fallback used as now.

In the above scenario adding paths to /etc/xdg.conf would not have any effect
if XDG_DATA_DIRS was set. That would make things rather unpredictable. I
think the paths in /etc/xdg.conf would need to be combined with the ones in
XDG_DATA_DIRS.

> this is what i've been asking for since 3.4 and the beginning of the flood
> of XDG_DATA_DIRS-not-set-correctly related bugs on bugs.kde.org. i'd really
> like to see this happen because both ISVs and users struggle with the
> environment variable approach. since so many people struggle with it, i'd
> suggest that's empirical evidence that it sucks ;)

Watch out what you ask for, you may get it. With such scheme it means that
after installing 6 applications your search path for a number of resources
also becomes 6 path's longer. It also means that applications (in KDE's case
kded) will need to be modified to watch /etc/xdg.conf in order to pick up new
applications. Apart from that there will be a transition period in which only
recent applications/distributions will support /etc/xdg.conf.

If there is concensus that that is the right long term direction and that the
benefits outweigh the disadvantages then I guess we should go that way. I
would like to hear some more cheers of support for that direction first
though.

Cheers,
Waldo

-------------------------------------------------------