trinity-devel@lists.pearsoncomputing.net

Message: previous - next
Month: January 2012

Re: [trinity-devel] Need help: cmake/pkgconfig breakage?

From: "E. Liddell" <ejlddll@...>
Date: Thu, 19 Jan 2012 19:16:19 -0500
On Thu, 19 Jan 2012 15:12:23 -0800 (PST)
Darrell Anderson <humanreadable@...> wrote:

> > <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.

The solution used by Gentoo for installing KDE3 and KDE4 in parallel was to filter the
$PATH variable in startkde by using sed--if the startkde for KDE3 was invoked, KDE4 
directories would be filtered out of the path, and vice-versa. That fixes most of the 
problems you describe (invoking a KDE4 application while running KDE3/Trinity 
does require the full path to be given, but that's a minor flaw compared to not knowing 
which app you're going to be getting), although I admit it isn't elegant.