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// 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 To: xdg@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 -------------------------------------------------------