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

[Ngie Cooper (yaneurabeya)]

> On Mar 7, 2017, at 01:04, Rodney W. Grimes <freebsd at pdx.rh.CN85.dnsmgr.net> wrote:
> 
>>> 
>>> On Mar 6, 2017, at 21:50, Rodney W. Grimes <freebsd at pdx.rh.CN85.dnsmgr.net> wrote:
>>> 
>>>>> On Mar 6, 2017, at 21:10, Rodney W. Grimes <rgrimes at 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.

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.

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.

Thanks,
-Ngie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/svn-src-all/attachments/20170307/c0dfb8da/attachment.sig>