Date: Tue, 6 Feb 2018 15:18:42 -0800 From: Mark Millard <marklmi26-fbsd@yahoo.com> To: Ian Lepore <ian@FreeBSD.org>, svn-src-head@freebsd.org Subject: Re: svn commit: r328934 - in head: . bin/sh Message-ID: <D8D38103-4E88-4FF2-BBEB-36770FA16E09@yahoo.com>
next in thread | raw e-mail | index | archive | help
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)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D8D38103-4E88-4FF2-BBEB-36770FA16E09>