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.