|
On 05/04/2018 09:42 AM, John Florian
wrote:
On 2018-05-04 09:33, Stephen John Smoogen wrote:
I would do so for the following reasons:
1. Even though the security arguments are weak, they are going
to be
checkmarks on audits which can't be changed for years.
2. When someone gets a "remove this and find out why the OS did
this"
it helps if they can point to an "official" change versus an
email.
This is an excellent point. Chasing the history of such changes
through myriad email is always frustrating, especially since it's
often inconclusive of what actually did happen.
Just checking my own PATH, I see some surprising things at the
front:
$ echo $PATH
/usr/libexec/python3-sphinx:/usr/lib64/qt-3.3/bin:/usr/lib64/ccache:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin
I love Sphinx and Qt, but what are they doing there ... at the
front? If nothing else, that seems an inefficient search order.
Yeah, caching will alleviate most of that, so why are they there
at all?
Yeah, I don't like it either. Even if there are reasons for those
two, it's a bad precedent---if every package did that, $PATH would
become unmanageable, and impossible to audit. Furthermore, the way
these two insert stuff into my $PATH is quirky/hacky: they drop
files into /etc/profile.d that cover csh and sh
- python-sphinx runs 'module load python-sphinx' from
/usr/share/modulefiles/python-sphinx/python2-sphinx which does
'prepend-path'
- qt just executes a shell script that manipulates $QT* and
$PATH
Since the main reason to mess with $PATH ordering is to override
same-named commands, I think we should have a guideline that
packages do not mess with path, or at least don't prepend to it.
BTW, on my system, ktechlab also messes with $PATH but at least
it _appends_ /usr/libexec/sdcc to it. Still, I think sdcc should
just go to /bin...
|
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
