From owner-svn-src-head@freebsd.org Tue Mar 7 09:31:31 2017 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1E31CD00C6F; Tue, 7 Mar 2017 09:31:31 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id ECD631FC5; Tue, 7 Mar 2017 09:31:30 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id v279VTCA093743; Tue, 7 Mar 2017 01:31:29 -0800 (PST) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id v279VSng093742; Tue, 7 Mar 2017 01:31:28 -0800 (PST) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <201703070931.v279VSng093742@pdx.rh.CN85.dnsmgr.net> Subject: Re: svn commit: r314833 - in head: bin/pkill lib/libxo/tests/encoder libexec/rtld-elf share/termcap usr.bin/chpass usr.bin/passwd usr.sbin/bsdinstall/partedit usr.sbin/mailwrapper usr.sbin/nologin In-Reply-To: To: "Ngie Cooper (yaneurabeya)" Date: Tue, 7 Mar 2017 01:31:28 -0800 (PST) CC: rgrimes@freebsd.org, src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org Reply-To: rgrimes@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.23 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, 07 Mar 2017 09:31:31 -0000 -- Start of PGP signed section. [ Charset UTF-8 unsupported, converting... ] > > > On Mar 7, 2017, at 01:04, Rodney W. Grimes wrote: > > > >>> > >>> On Mar 6, 2017, at 21:50, Rodney W. Grimes wrote: > >>> > >>>>> On Mar 6, 2017, at 21:10, Rodney W. Grimes wrote: > >>>>> > >>>>> Author: rgrimes > >>>>> Date: Tue Mar 7 05:10:38 2017 > >>>>> New Revision: 314833 > >>>>> URL: https://svnweb.freebsd.org/changeset/base/314833 > >>> ... > >>> > >>>>> > >>>>> -SYMLINKS+= ${LIBDIR}/${SHLIB_NAME} /usr/lib/libxo/encoder/test.enc > >>>>> +SYMLINKS+= ../../../tests/lib/libxo/${SHLIB_NAME} /usr/lib/libxo/encoder/test.enc > >>>> > >>>> This change breaks setting TESTSBASE != /usr/tests . Please fix (my employer depends on this being functional). > >>>> Thanks, > >>> > >>> I am just going to revert this until the issue with SYMLINKS vs RSYMLINKS and > >>> probably a much better fix in bsd.*.mk can be implemented. I can live with > >>> one last nasty wart of an absolute link in DESTDIR until then. The important > >>> functional ones are gone now. > >>> > >>> To fix this without changing SYMLINKS would involve adding a local install: > >>> target which would be more mess than having the one absolute link. > >> > >> The proposed enhancement for bsd.links.mk for RSYMLINKS can be found here: https://reviews.freebsd.org/D9919 . > > > > I dont think that is what bapt/bdrewery had in mind, I think they wanted to > > replicate the SYMLINK= as RSYMLINK= and use that when needed. > > > > I have thought about this and we do not ever want absolute links in the tree, > > so much simpler fix is to just convert SYMLINKS to call INSTALL_RSYMLINKS > > instead of INSTALL_SYMLINKS and bam, its all fixed and shall always be fixed, > > and as long as no one uses INSTALL_SYMLINKS. > > SYMLINKS has been around since r245752. I personally don?t know if it?s wise to remove functionality that?s been ?in production? for 4+ years. SYMLINKS has been around since 198x. > Making the target intelligently use one command over the other might seem ok, but it could have unintended consequences. > I think it?s best to have another well-documented variable that uses INSTALL_RSYMLINK vs INSTALL_SYMLINK. It has 0 consequencies, it actually achives that all installed symbolic links be relative, which is how things should be. There is no doubt about this, if you have doubt please defer to myself, Julian Elisher and some other grey beards that know about this. You simply do NOT want absolute path symbolic links in the distribution, ever! > Also, in the CR, please note that the SYMLINKS piece doesn?t prefix source targets with ${DESTDIR}, whereas the LINKS (and soon to be RSYMLINKS portion) will need it in order to compute the right paths and execute the right behavior. Otherwise, you?re going to be breaking someone?s use for SYMLINKS for no good reason. That is correct, LINKS need 2 absolute paths to things in DESTDIR to create the proper hardlink, where as SYMLINKS need the prooper DESTDIR relative source to place as the link body at the target. I suggest your run a make installworld DESTDIR=/some/place and see just how broken your symbolic links end up if you add ${DESTDIOR] to both sides of SYMLINK > -Ngie -- Rod Grimes rgrimes@freebsd.org