> <warning a bit of a rant follows> > ... > /<warning a bit of a rant follows> I understand your reasoning. I have run into path issues that are caused by installing to /opt/trinity and I have filed bug reports. As a team we need to resolve these types of bugs before R14. Even if the bugs prove to be PEBKAC, we need to provide that information on the wiki so people avoid these traps. Installing to /usr/local won't solve all path problems --- when KDE4 is installed too. A challenge with Trinity and KDE4 coexisting is the names of so many apps and shared libraries have the same name. Searching for apps is dependent upon the $PATH variable. Placing apps in /usr/local/bin means /usr/local/bin needs to be before /usr/bin in the search path, which normally is true. Yet how do users run KDE4 in that environment? Only full path names will resolve the problem because of the duplicate names. The same thing happens with installing to /opt/trinity. /opt/trinity/bin needs to be first in $PATH, but how do KDE4 users run their apps. What happens in a multi-user system? I can solve these problems on a system with one user by removing KDE4 from the system. When I do that then I might as well build my packages to install to /usr rather than /usr/local or /opt/trinity. I can't do that in a multi-user system because users have their desktop preferences. There also are people who run both Trinity and KDE4. How should they configure a system to avoid path conflicts and apps with the same name? The problem is all of those apps and libraries with the same name. Part of the problem is the various Trinity *.desktop files default to only the executable name rather than using a full path. As long as Trinity is forced to play second fiddle with KDE4, then I think we should revise all *.desktop files to include full paths to the executables. This is something that needs to done during compiling. These path conflicts are different than the problem I had with pkg-config and $CPLUS_INCLUDE_PATH. :) Configuring pkgconfig files is a matter of packaging and ensuring *.pc files are findable through the $PKG_CONFIG_PATH environment variable. The problem affecting my build environment is a weird anomaly that even if explainable, is just plain difficult to troubleshoot. My build environment was finding the *.pc files but something with the $CPLUS_INCLUDE_PATH variable causes breakage. Rants are good to raise awareness. I like rants. :) I have raised some of these path conflict issues here before but all I received was silence. As a team we need to address various peculiarities users might experience when both KDE4 and Trinity are installed on the same system. As a team we need to ensure developers and packagers are testing in such an environment. If everybody merely rips KDE4 from their system to use Trinity then that is the same as sticking our heads in the sand. :) If we stick our heads in the sand we get a bad reputation. :( Darrell