22 May
2024
22 May
'24
4:35 a.m.
On 5/21/24 11:14 PM, Felix Miata via tde-users wrote:
My point was *most* users on *most* distros have a
~/.bashrc file, whether they
know it or not, and whether they consciously or not do anything that may be
affected by anything in it.
When a user does not use bash as the default shell, then anything inside
.bashrc or any of the other bash startup scripts are irrelevant because
the files do not get sourced. Adding /opt/trinity/bin to the user's
$PATH in .bashrc is not going to do anything.
Suppose though a user discovers that TDE software can't be used within a
different DE and finds a way to massage $PATH to place /opt/trinity/bin
after /usr/bin. Some people are willing to invest that kind of sweat
equity. Most won't, simply muttering WTF. This is part of the point
about installing TDE in /usr. Doing that means there are not going to be
any environment variable issues.
In that use case, placing /opt/trinity/bin after /usr/bin is important.
Otherwise all binaries in /opt/trinity/bin prevail over those in
/usr/bin. If that person is using KDE and wants to use an occasional TDE
tool then I'll guess the user will get frustrated and mad.
I was there when starttde was first massaged into a complex script. I
contributed my share of the code. Everybody involved worked hard to
anticipate various usage scenarios. Unfortunately the script, and TDE in
general, is designed more or less as a sole DE. There is nothing wrong
with this approach, until a person wants to use multiple DEs or the
computer is used by multiple people where global environment variables
cause havoc.
Like I shared earlier, I am not trying to start a coup. There are some
issues with TDE that need attention, that's all. That TDE works great
for you in /opt is nice, but we live in a big world with many different
use cases. None of the other DEs installed in /usr face these issues.
And if or when the devs agree to pursue this issue, everything will be
tested in a git branch, not in production.