Like "ln -s -r" from GNU coreutils. Shouldn't be too difficult to emulate this in bash for non-coreutils implementations of ln. For example, eselect is already doing this: https://gitweb.gentoo.org/proj/eselect.git/tree/libs/path-manipulation.bash.in#n69
It should probably come with a big fat note that it won't figure out symlinks if they get in the way.
(In reply to Michał Górny from comment #1) > It should probably come with a big fat note that it won't figure out > symlinks if they get in the way. Relative symlinks should work, I think, because the paths are canonicalised. If the image in ${D} contains absolute links then you lose of course.
In #gentoo-qa we came up with this: - dosym without option accepts only a relative path as first argument - dosym -r expands the first arg relative to the link location - dosym -l (or -a for "absolute"?) treats the first arg as a literal string
(In reply to Ulrich Müller from comment #2) > (In reply to Michał Górny from comment #1) > > It should probably come with a big fat note that it won't figure out > > symlinks if they get in the way. > > Relative symlinks should work, I think, because the paths are canonicalised. > If the image in ${D} contains absolute links then you lose of course. I meant directory symlinks along the way. E.g.: ROOT has /a/b -> ../c D has plain /a/b directory you 'dosym -r /a/d /a/b/c' you get ../d as target I think we should just make it clear that '-d' doesn't work if there are directory symlinks along the way, whether they are reproduced in D or not.
I think the spec would define that both target and directory will be canonicalised by the same algorithm as used in "readlink -f". Portage already has a canonicalize() shell replacement in misc-functions.sh, so we don't have to worry about systems where readlink doesn't support the -f option. Alternatively, we could canonicalise using "realpath -m -s" from >=coreutils-8.15, which would purely act on the string, without looking at the filesystem. But IMHO that would be inferior to the above method.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/portage.git/commit/?id=dfa50503f76f3e70bac50f959a9c7248e6ea880d commit dfa50503f76f3e70bac50f959a9c7248e6ea880d Author: Ulrich Müller <ulm@gentoo.org> AuthorDate: 2020-11-23 09:06:49 +0000 Commit: Zac Medico <zmedico@gentoo.org> CommitDate: 2021-05-24 05:55:41 +0000 dosym: Implement -r option for EAPI 8. "dosym -r <target> <link>" will expand the (apparent) path of <target> relative to the (apparent) path of the directory containing <link>. The main aim of this is to allow for an absolute path to be specified as the link target, and the function will count path components and convert it into a relative path. Since we're inside ED at this point but the image will finally be installed in EROOT, we don't try to resolve any pre-existing symlinks in <target> or <link>. In other words, path expansion only looks at the specified apparent paths, without touching any actual files in ED or EROOT. Bug: https://bugs.gentoo.org/708360 Signed-off-by: Ulrich Müller <ulm@gentoo.org> Signed-off-by: Michał Górny <mgorny@gentoo.org> Signed-off-by: Zac Medico <zmedico@gentoo.org> bin/eapi.sh | 4 +++ bin/ebuild-helpers/dosym | 67 +++++++++++++++++++++++++++++++++++++++++++++++- 2 files changed, 70 insertions(+), 1 deletion(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/pms.git/commit/?id=42fdc187b717120717e55d9b1bee06a764e55b5d commit 42fdc187b717120717e55d9b1bee06a764e55b5d Author: Ulrich Müller <ulm@gentoo.org> AuthorDate: 2021-05-16 18:22:15 +0000 Commit: Ulrich Müller <ulm@gentoo.org> CommitDate: 2021-06-05 08:55:40 +0000 EAPI 8 has dosym -r Bug: https://bugs.gentoo.org/708360 Signed-off-by: Ulrich Müller <ulm@gentoo.org> eapi-differences.tex | 4 ++++ pkg-mgr-commands.tex | 39 ++++++++++++++++++++++++++++++++++++--- 2 files changed, 40 insertions(+), 3 deletions(-)
