From owner-svn-src-head@freebsd.org Tue Feb 6 23:18:52 2018 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EF323F11576 for ; Tue, 6 Feb 2018 23:18:51 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) Received: from sonic307-4.consmr.mail.bf2.yahoo.com (sonic307-4.consmr.mail.bf2.yahoo.com [74.6.134.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 98EBC68EF6 for ; Tue, 6 Feb 2018 23:18:51 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) X-YMail-OSG: 7Jx5b7QVM1mPNDJIaovyDCty4FjxYvGcBA8LG7H02Rkf6RoqKk4QTElElFLHtg2 USouqEFVowVdfsHNcSBxRY8fMFcG2gnjTCZJWnLxBOgF.ZWaJnmOn83GeL1np1MljJdUFNVc7H4G olxFxyWRHDAIpMn99Sd7eUkotR9msETEdAtBom9iMKzr5JZ9w8mai7EnzeCIPhj36dUrV1IQwbm1 BBBu5NWXwQfRkyg7rDhmYkg9gs8yqwjRse5dlgf7ukNXPjODPc3iQrZlaCHTPgLGthgKCC9tjcUJ pWni7AVRVXYvKexuiloyZxt_ubf2ax3IJMFSY9qf8FEEIr75NQjYefm0GwJPmojeZKWkW8EWulLB 6YsNPPGsAuaDZ3J6WFNjh5X_3geAkyjeIUsI5JSU6K1e4Gx3DRsCjOt6QuMZU_JNrExCKkHQEKb0 nC9NTb7xPglWjHuhl5rjfmedtrM2dTTqcDL86XyywK.p11ovs8qwKH3rUft4ZZN1WREMY Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.bf2.yahoo.com with HTTP; Tue, 6 Feb 2018 23:18:45 +0000 Received: from smtpgate101.mail.bf1.yahoo.com (EHLO [192.168.1.25]) ([72.30.28.45]) by smtp413.mail.bf1.yahoo.com (JAMES SMTP Server ) with ESMTPA ID 192053ffaa254a502feef3930eb7078e; Tue, 06 Feb 2018 23:18:44 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: svn commit: r328934 - in head: . bin/sh Message-Id: Date: Tue, 6 Feb 2018 15:18:42 -0800 To: Ian Lepore , svn-src-head@freebsd.org X-Mailer: Apple Mail (2.3445.5.20) X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Feb 2018 23:18:52 -0000 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)