Date: Tue, 7 Mar 2017 01:31:28 -0800 (PST) From: "Rodney W. Grimes" <freebsd@pdx.rh.CN85.dnsmgr.net> To: "Ngie Cooper (yaneurabeya)" <yaneurabeya@gmail.com> Cc: rgrimes@freebsd.org, src-committers <src-committers@freebsd.org>, svn-src-all@freebsd.org, svn-src-head@freebsd.org 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 Message-ID: <201703070931.v279VSng093742@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <C564389B-E51F-439B-843C-8EFE9EAD9EE4@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
-- Start of PGP signed section. [ Charset UTF-8 unsupported, converting... ] > > > On Mar 7, 2017, at 01:04, Rodney W. Grimes <freebsd@pdx.rh.CN85.dnsmgr.net> wrote: > > > >>> > >>> On Mar 6, 2017, at 21:50, Rodney W. Grimes <freebsd@pdx.rh.CN85.dnsmgr.net> wrote: > >>> > >>>>> On Mar 6, 2017, at 21:10, Rodney W. Grimes <rgrimes@FreeBSD.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201703070931.v279VSng093742>