On Thursday 19 January 2012 06:12:23 pm Darrell Anderson 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.

Well yes, but TDE should be able to be built into any directory place withn in 
reason and it should work.

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

It helps me get past the path issues and that uglyness, then I am only left to 
fight with the "real" issues and test it.  I came to this position after the 
trouble I had trying to build the packages that used autotools.  That was 
horrible. What I ended up doing was to simplify by ripping out all the 
path/pkg-config/linker and god only knows what else.  Now it mostly ujst 
builds.  If I have a header file or lib that can not be found I only need to 
look at that.  There are a lot of variables/paths tweaks I see in most 
everybodies scripts that I don't need or have a problem with.

Would having tde able to be build solidily with a minimum amount of trouble be 
good and then all the energy spent just trying to get it built could be 
directed at getting tit to work with KDE4 be better?

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

Yes I know that, but until the executable names are changed I don't see how 
this will ever be solved completely. ( see below )

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

Yes I know.

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

Then TDE is tied into being in a certain place unless the packager handles 
changing all the pathing issues/changes in the desktop files.  Sounds ugly.

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

This is one of the reasons I changed to using /usr/local.  I don't have to use 
$CPLUS_INCLUDE_PATH or any of the "other nonsense" to get tde to build.

Have a look at my scripts on github or gitorius.  You will see they don't have 
a lot of that kind of thing going on.  They are pretty straight forward. 
configure && make && and install, package it up and then next package.
After I slayed the qt3 problem all was good.

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

Not really, it needs to be able to be built easily as well as mostly finished.  
Don't want to many beasts to slay at one time, if you get my drift.

>
> If we stick our heads in the sand we get a bad reputation. :(
>

Sure, my goals are a but different.  Keep it simple
Get TDE stable/buildable until it get to the point that it builds on most 
distros.  Then go wild on bending and breaking it. ;)

There is a lot of work left to do.  Including intergrating into a system with 
other desktop GUIs.

I see stable first then integrate.