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

[Rodney W. Grimes]

[ Charset ISO-8859-1 unsupported, converting... ]
> On Tue, 2018-02-06 at 11:25 -0800, Rodney W. Grimes wrote:
> > > 
> > > Author: arichardson
> > > Date: Tue Feb??6 15:41:35 2018
> > > New Revision: 328934
> > > URL: https://svnweb.freebsd.org/changeset/base/328934
> > > 
> > > Log:
> > > ? Don't hardcode /usr/bin as the path for mktemp in build tools
> > > ??
> > > ? It won't work e.g. when crossbuilding from Ubuntu Linux as mktemp
> > > is in
> > > ? /bin there.
> > > ??
> > > ? Reviewed By:	bdrewery
> > > ? Approved By:	jhb (mentor)
> > > ? Differential Revision: https://reviews.freebsd.org/D13937
> > Would it be better to create the variable MKTEMP to point at
> > either /bin/mktemp or /usr/bin/mktemp dependent on platform,
> > there are reasons we use full paths in Makefiles, mostly to
> > stop /usr/local/bin/foo contimaton, which I believe this
> > change now opens up, though very slight as I dont know of
> > a third party mktemp binary.
> > 
> 
> 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.

Your welcome to wonder down that twisty maze of passages, I however
shall not be following you.

If you start to accept what ever the users path is for building
the freebsd /usr/src tree the rate of failed builds and complaints,
and hours spent chasing after oh crap it picked up foo from /usr/local
is not a game I care to par take in. 

You personally, could probably get away with this and be fine,
our user base would probably not be very lucky.w

Oh, and reproducibility goes totally out the window if you fool with that.

> -- Ian

-- 
Rod Grimes                                                 rgrimes at freebsd.org