[OE-core] update-alternatives + absolute links

[Patrick Ohly]

On Tue, 2016-02-09 at 12:03 +0100, Patrick Ohly wrote:
> Hello!
> 
> I noticed that toybox's switch_root has problems handling /sbin/init
> -> /lib/systemd/systemd. Apparently it tries to check permissions with
> stat() before switching the root, and at that point resolving the
> symlink fails.
> 
> Are there reasons for preferring absolute paths as link target? Using
> relative paths would avoid the problem, and also make it easier to
> investigate the content of the rootfs on the build host.
> 
> Is that something that would have to be fixed in the different
> virtual/update-alternatives providers? I'm using opkg-utils at the
> moment.

Here's a proof-of-concept patch that modifies opkg-utils-native so that
it calls lnr for turning the absolute link target into something
relative. This turned out to be more complex than anticipated, so a
proper patch instead of the sed mangling would be more appropriate now.

It is limited to opkg-utils-native and thus image creation. On the
target it's harder: "ln --relative" only works for coreutils, lnr is not
installed, and Python cannot be taken for granted either.

Not sure how to proceed. Perhaps its not worth changing after all.

diff --git a/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb b/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb
index 1bc561c..4ea7132 100644
--- a/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb
+++ b/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb
@@ -38,6 +38,12 @@ do_install_append_class-target() {
        fi
 }
 
+do_install_append_class-native() {
+       if [ -e "${D}${bindir}/update-alternatives" ]; then
+               sed -i ${D}${bindir}/update-alternatives -e 's!ln -snf .*!case "$path" in /*) realpath="$D$path"; rm -f $link \&\& lnr $realpath $link;; *) ln -snf $path $link;; esac!'
+       fi
+}
+
 PACKAGES =+ "update-alternatives-opkg"
 FILES_update-alternatives-opkg = "${bindir}/update-alternatives"
 RPROVIDES_update-alternatives-opkg = "update-alternatives update-alternatives-cworth"

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.