<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