$ mkdir /tmp/lib/ /tmp/libexec $ touch /tmp/lib/foo.so $ install -lrs /tmp/lib/foo.so /tmp/libexec/ $ ls -l /tmp/libexec total 1 lrwxr-xr-x 1 mat wheel 9 30 janv. 20:34 foo.so -> ../foo.so This only happens with absolute paths, and only, from what I undestand with a bit of testing, if the first path matches the second. As in "/tmp/lib" is present in "/tmp/libexec", so, hey, they must be the same, so stop here, but "/tmp/libexec" is not in "/tmp/lib" so add a "../" install -lrs is used quite a lot in the ports tree, and this bug broke at least a port. Also, an EN would be nice once this is fixed and merged to the different stable branches.
A commit references this bug: Author: kevans Date: Thu Jan 31 05:20:12 UTC 2019 New revision: 343601 URL: https://svnweb.freebsd.org/changeset/base/343601 Log: install(1): Fix relative path calculation with partial common dest/src For example, from the referenced PR [1]: $ mkdir /tmp/lib/ /tmp/libexec $ touch /tmp/lib/foo.so $ install -lrs /tmp/lib/foo.so /tmp/libexec/ The common path identification bits terminate src at /tmp/lib/ and the destination at /tmp/libe. The subsequent backtracking is then incorrect, as it traverses the destination and backtraces exactly one level while eating the 'libexec' because it was previously (falsely) identified as common with 'lib'. The obvious fix would be to make sure we've actually terminated just after directory separators and rewind a character if we haven't. In the above example, we would end up rewinding to /tmp/ and subsequently doing the right thing. Test case added. PR: 235330 [1] MFC after: 1 week Changes: head/usr.bin/xinstall/tests/install_test.sh head/usr.bin/xinstall/xinstall.c
A commit references this bug: Author: kevans Date: Sat Feb 16 04:48:31 UTC 2019 New revision: 344205 URL: https://svnweb.freebsd.org/changeset/base/344205 Log: MFC r343601: install(1): Fix relative path calculation with partial common dest/src For example, from the referenced PR [1]: $ mkdir /tmp/lib/ /tmp/libexec $ touch /tmp/lib/foo.so $ install -lrs /tmp/lib/foo.so /tmp/libexec/ The common path identification bits terminate src at /tmp/lib/ and the destination at /tmp/libe. The subsequent backtracking is then incorrect, as it traverses the destination and backtraces exactly one level while eating the 'libexec' because it was previously (falsely) identified as common with 'lib'. The obvious fix would be to make sure we've actually terminated just after directory separators and rewind a character if we haven't. In the above example, we would end up rewinding to /tmp/ and subsequently doing the right thing. Test case added. PR: 235330 [1] Changes: _U stable/12/ stable/12/usr.bin/xinstall/tests/install_test.sh stable/12/usr.bin/xinstall/xinstall.c
A commit references this bug: Author: kevans Date: Sat Feb 16 04:49:10 UTC 2019 New revision: 344206 URL: https://svnweb.freebsd.org/changeset/base/344206 Log: MFC r343601: install(1): Fix relative path calculation with partial common dest/src For example, from the referenced PR [1]: $ mkdir /tmp/lib/ /tmp/libexec $ touch /tmp/lib/foo.so $ install -lrs /tmp/lib/foo.so /tmp/libexec/ The common path identification bits terminate src at /tmp/lib/ and the destination at /tmp/libe. The subsequent backtracking is then incorrect, as it traverses the destination and backtraces exactly one level while eating the 'libexec' because it was previously (falsely) identified as common with 'lib'. The obvious fix would be to make sure we've actually terminated just after directory separators and rewind a character if we haven't. In the above example, we would end up rewinding to /tmp/ and subsequently doing the right thing. Test case added. PR: 235330 [1] Changes: _U stable/11/ stable/11/usr.bin/xinstall/tests/install_test.sh stable/11/usr.bin/xinstall/xinstall.c
The fix for this made it into 11.2-RELEASE-p10 and 12.0-RELEASE-p4, along with all supported branches. Closing this as FIXED now.