svn commit: r328934 - in head: . bin/sh

[Mark Millard]

Ian Lepore ian at freebsd.org wrote on
Tue Feb 6 19:35:21 UTC 2018 :

> I don't understand this idea of /usr/local "polluting" a system.  It
> seems to me exactly the opposite would be the case... if I have found
> some 3rd party version of mktemp that I like better, it would be
> installed in /usr/local.  If I went out of my way to install that, then
> naturally I WANT it to be used.  To me, it's insane that the /usr/local
> paths are not in front of the base system paths by default, and it's
> even more insane that the base system works so hard to NOT use the
> replacements I've installed (even if I've arranged PATH so that the
> right versions should be used) so that I have to track down why it's
> using the wrong thing and apply ad-hoc fixes.


I've had mixed results over the years. I've had ports install files
for other 'internal' purposes (not my overall goals) that in turned
broke buildworld for powerpc(64) for some alternative compiler/tool
chains that induced /usr/local/ header file usage if a file name
accidentally matched. There was a period of time where I'd rename
some specific header files as I switched activities in order to avoid
systematic problems. (It seemed easier than than other alternatives
that I considered at the time.)

[But I've been doing odd "target powerpc64 and powerpc without gcc
4.2.1" experiments for a few years. Not exactly a typical context.]

As the build system for buildworld has progressed, I've not had such
problems for some time: it became easier to avoid /usr/local/include/
getting involved, at least for what I've been doing. Also, I do
external toolchain activity less often these days.

===
Mark Millard
marklmi at yahoo.com
( markmi at dsl-only.net is
going away in 2018-Feb, late)