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

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