core: ensure we use the realpath(3) of DL_DIR
PATCH 1/1 core: ensure we use the realpath(3) of DL_DIR
When $(TOPDIR)/dl is a symlink, checking out git submodules can fail, as reported by Michael in #11086.
To reproduce a similarly-related mis-behaviour:
$ mkdir -p foo/bar foo/buz
$ cd foo/bar
$ ln -s ../buz meh
$ cd meh
$ cd ../../fooThe last command should not succeed, because, relative to meh, there is no ../../foo directory; we would expect it to be ../../../foo, instead. But since meh is a symlink to a directory, then a relative path from that symlink is interpreted as relative to the derefrenced directory, i.e. from buz in this case.
But where this gine even werider, is that, if the last command is replaced by:
$ cd ../../../foo
then it still works, too.
And that is the root of Michael's issue: the dl directory in Buildroot's TOPDIR is a symlink to a similarly-named directory one directory higher, which then confuses relative paths, which gets especially and noticeably bad for git submodules.
Avoid this strangeness, and just use so-called "physical" path, i.e. a path where all symlinks to directories have been dereferenced.
--- package/pkg-download.mk | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
package/pkg-download.mk +2 -2
@@ -32,8 +32,8 @@ else BR2_DL_DIR = $(DL_DIR) endif -# ensure it exists and a absolute path -DL_DIR := $(shell mkdir -p $(DL_DIR) && cd $(DL_DIR) >/dev/null && pwd) +# ensure it exists and a absolute path, derefrecing symlinks +DL_DIR := $(shell mkdir -p $(DL_DIR) && cd $(DL_DIR) >/dev/null && pwd -P) # # URI scheme helper functions
Signature · 1 line
2.14.1
PATCH 1/1 core: ensure we use the realpath(3) of DL_DIR
Quoted 31 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Yann" == Yann E MORIN <[email protected]> writes:
When $(TOPDIR)/dl is a symlink, checking out git submodules can fail, as reported by Michael in #11086.
To reproduce a similarly-related mis-behaviour:
$ mkdir -p foo/bar foo/buz $ cd foo/bar $ ln -s ../buz meh $ cd meh $ cd ../../fooThe last command should not succeed, because, relative to meh, there is no ../../foo directory; we would expect it to be ../../../foo, instead. But since meh is a symlink to a directory, then a relative path from that symlink is interpreted as relative to the derefrenced directory, i.e. from buz in this case.
But where this gine even werider, is that, if the last command is replaced by:
$ cd ../../../foothen it still works, too.
And that is the root of Michael's issue: the dl directory in Buildroot's TOPDIR is a symlink to a similarly-named directory one directory higher, which then confuses relative paths, which gets especially and noticeably bad for git submodules.
Quoted 8 lines
Avoid this strangeness, and just use so-called "physical" path, i.e. a path where all symlinks to directories have been dereferenced.
Fixes #11086Reported-by Michael Nosthoff <[email protected]>Signed-off-by "Yann E. MORIN" <[email protected]>Cc Michael Nosthoff <[email protected]>
Committed, thanks.
Signature · 1 line
Bye, Peter Korsgaard
PATCH 1/1 core: ensure we use the realpath(3) of DL_DIR
In reply to Yann E. MORINQuoted 31 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Yann" == Yann E MORIN <[email protected]> writes:
When $(TOPDIR)/dl is a symlink, checking out git submodules can fail, as reported by Michael in #11086.
To reproduce a similarly-related mis-behaviour:
$ mkdir -p foo/bar foo/buz $ cd foo/bar $ ln -s ../buz meh $ cd meh $ cd ../../fooThe last command should not succeed, because, relative to meh, there is no ../../foo directory; we would expect it to be ../../../foo, instead. But since meh is a symlink to a directory, then a relative path from that symlink is interpreted as relative to the derefrenced directory, i.e. from buz in this case.
But where this gine even werider, is that, if the last command is replaced by:
$ cd ../../../foothen it still works, too.
And that is the root of Michael's issue: the dl directory in Buildroot's TOPDIR is a symlink to a similarly-named directory one directory higher, which then confuses relative paths, which gets especially and noticeably bad for git submodules.
Quoted 8 lines
Avoid this strangeness, and just use so-called "physical" path, i.e. a path where all symlinks to directories have been dereferenced.
Fixes #11086Reported-by Michael Nosthoff <[email protected]>Signed-off-by "Yann E. MORIN" <[email protected]>Cc Michael Nosthoff <[email protected]>
Committed to 2018.02.x and 2018.08.x, thanks.
Signature · 1 line
Bye, Peter Korsgaard