system: make sh symlink match original busybox symlink path
PATCH 1/1 system: make sh symlink match original busybox symlink path
The symlink created by buildroot for /bin/sh when busybox is used is the full path to /bin/busybox and does not match the symlink created by busybox for /bin/sh, which is just busybox. When handling files on the host system this will point to the host system's busybox if present and not the target busybox.
This is fixed by changing the /bin/sh symlink to just be busybox since both files are in the same directory.
--- system/Config.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
system/Config.in +1 -1
@@ -236,7 +236,7 @@ endchoice # /bin/sh config BR2_SYSTEM_BIN_SH string - default "/bin/busybox" if BR2_SYSTEM_BIN_SH_BUSYBOX + default "busybox" if BR2_SYSTEM_BIN_SH_BUSYBOX default "/bin/bash" if BR2_SYSTEM_BIN_SH_BASH default "/bin/dash" if BR2_SYSTEM_BIN_SH_DASH default "/bin/zsh" if BR2_SYSTEM_BIN_SH_ZSH
Signature · 1 line
2.1.4
PATCH 1/1 system: make sh symlink match original busybox symlink path
Matthew, All,
On 2015-06-16 10:41 -0500, Matthew Starr spake thusly:
Quoted 5 lines
The symlink created by buildroot for
/bin/shwhen busybox is used is the full path to/bin/busyboxand does not match the symlink created by busybox for/bin/sh, which is just busybox. When handling files on the host system this will point to the host system's busybox if present and not the target busybox.
I fail to see the problem that would cause. We have quite a few other absolute symlinks. Do we want to fix all of them?
Note: yes, I thinf I know what your problenm is, that is checksuming-or-such the content of each file. I believe this is wrong, because that would miss the information that this is actually a *symlink*, and would not detect the fact that is is replacec with an actual file (and hence takes more place on the device than is expected).
I would find it much smarter that:
- files get their content checksumed
- symlinks get their target path checksumed, not the content of the target file (or dir). I.e. symlinks should not be dereferenced.
Quoted 13 lines
This is fixed by changing the
/bin/shsymlink to just be busybox since both files are in the same directory.Signed-off-by Matthew Starr <[email protected]>--- system/Config.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)system/Config.in +0
-0
system/Config.in endchoice # /bin/sh · line 239
Quoted 5 lines
system/Config.in +1
-1@@ -236,7 +236,7 @@ endchoice # /bin/sh config BR2_SYSTEM_BIN_SH string - default "/bin/busybox" if BR2_SYSTEM_BIN_SH_BUSYBOX + default "busybox" if BR2_SYSTEM_BIN_SH_BUSYBOX
Please, keep the alignment of the if-clause.
system/Config.in endchoice # /bin/sh · line 242
Quoted 3 lines
system/Config.in +0
-0default "/bin/bash" if BR2_SYSTEM_BIN_SH_BASH default "/bin/dash" if BR2_SYSTEM_BIN_SH_DASH default "/bin/zsh" if BR2_SYSTEM_BIN_SH_ZSH
If you contend that /bin/sh being an absolute symlink is an issue, then surely the other shells should be treated the same, i.e. they should be madde relative symlinks.
All that matters in the end is that the symlink is correct *on the target". I'm not sure this change is interesting without a good reason; and I don't think you 10.192.168.1gave a good-enough reason; saying "the symlink is different than what busybox installs" is not a valid reason IMHO.
Regards,
Yann E. MORIN.
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------'
PATCH 1/1 system: make sh symlink match original busybox symlink path
Yann, All,
Quoted 5 lines
-----Original Message-----
From: Yann E. MORIN [mailto:yann.morin.1998 at gmail.com] Matthew, All,On 2015-06-16 10:41 -0500, Matthew Starr spake thusly:
Quoted 8 lines
Quoted 5 lines
The symlink created by buildroot for
/bin/shwhen busybox is used is the full path to/bin/busyboxand does not match the symlink created by busybox for/bin/sh, which is just busybox. When handling files on the host system this will point to the host system's busybox if present and not the target busybox.I fail to see the problem that would cause. We have quite a few other absolute symlinks. Do we want to fix all of them?
This is an absolute symlink that will affect everyone who may want to perform a checksum of the system or possibly perform other actions on files for the target while on the host system. I have yet to encounter other symlinks that have this issue, not to say there aren't any, but this one is an important one.
Quoted 6 lines
Note: yes, I thinf I know what your problenm is, that is checksuming-or-such the content of each file. I believe this is wrong, because that would miss the information that this is actually a *symlink*, and would not detect the fact that is is replacec with an actual file (and hence takes more place on the device than is expected).
Yes, doing a checksum on the host and comparing to the installed target is the functionality I am using to ensure a correct install.
Quoted 5 lines
I would find it much smarter that:
- files get their content checksumed
- symlinks get their target path checksumed, not the content of the target file (or dir). I.e. symlinks should not be dereferenced.
I agree this would be a smarter approach, but I have yet to see a simple utility to do this. Instead it is quite simple to just use md5sum in a script or md5deep. In the absence of such a utility, the easiest fix is to change the symlink that buildroot creates.
Additionally this was not an issue in previous versions of buildroot before BR2_SYSTEM_BIN_SH was created in 2014.11. In the previous version the /bin/sh symlink was just busybox.
Quoted 22 lines
Quoted 14 lines
This is fixed by changing the
/bin/shsymlink to just be busybox since both files are in the same directory.Signed-off-by Matthew Starr <[email protected]>--- system/Config.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)system/Config.in index renamed from system/Config.in +0
-084cde94..5c4ba90 100644
system/Config.in endchoice # /bin/sh · line 239
Quoted 5 lines
system/Config.in +1
-1@@ -236,7 +236,7 @@ endchoice # /bin/sh config BR2_SYSTEM_BIN_SH string - default "/bin/busybox" if BR2_SYSTEM_BIN_SH_BUSYBOX + default "busybox" if BR2_SYSTEM_BIN_SH_BUSYBOXPlease, keep the alignment of the if-clause.
Quoted 7 lines
system/Config.in endchoice # /bin/sh · line 242
Quoted 3 lines
system/Config.in +0
-0default "/bin/bash" if BR2_SYSTEM_BIN_SH_BASH default "/bin/dash" if BR2_SYSTEM_BIN_SH_DASH default "/bin/zsh" if BR2_SYSTEM_BIN_SH_ZSHIf you contend that
/bin/shbeing an absolute symlink is an issue, then surely the other shells should be treated the same, i.e. they should be madde relative symlinks.
I have looked at several different Linux distributions and they all seem to use relative paths for the /bin/sh symlink. Based on this then the /bin/sh symlink to bash, dash, and zsh should also be updated to be relative.
Quoted 5 lines
All that matters in the end is that the symlink is correct *on the target". I'm not sure this change is interesting without a good reason; and I don't think you 10.192.168.1gave a good-enough reason; saying "the symlink is different than what busybox installs" is not a valid reason IMHO.
Dealing with symlinks when you are not on the installed system or in a chroot environment is made more difficult by the use of absolute symlinks. If managing symlinks on the host is required, then just having it correct on the target is not enough.
Quoted 4 lines
Regards,
Yann E. MORIN.
Quoted 8 lines
--
.-----------------.--------------------.------------------.--------------------.| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' | conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |'------------------------------^-------^------------------^--------------------'
Best regards,
Matthew Starr
PATCH 1/1 system: make sh symlink match original busybox symlink path
Matthew, All,
[Please, wrap your lines at ~72 chars wide, it is easier to read...]
On 2015-06-16 12:31 -0500, Matthew Starr spake thusly:
Quoted 11 lines
Quoted 11 lines
-----Original Message-----
From: Yann E. MORIN [mailto:yann.morin.1998 at gmail.com] Matthew, All,On 2015-06-16 10:41 -0500, Matthew Starr spake thusly:
Quoted 5 lines
The symlink created by buildroot for
/bin/shwhen busybox is used is the full path to/bin/busyboxand does not match the symlink created by busybox for/bin/sh, which is just busybox. When handling files on the host system this will point to the host system's busybox if present and not the target busybox.
Quoted 7 lines
Quoted 2 lines
I fail to see the problem that would cause. We have quite a few other absolute symlinks. Do we want to fix all of them?
This is an absolute symlink that will affect everyone who may want to perform a checksum of the system or possibly perform other actions on files for the target while on the host system. I have yet to encounter other symlinks that have this issue,
/etc/mtab is an absolute symlink to /proc/mounts for example. This one comes from our skeletton, but I haven't looked if other packages are not installing absolute symlinks either.
Quoted 11 lines
not to say there aren't any, but
this one is an important one.Quoted 6 lines
Note: yes, I thinf I know what your problenm is, that is checksuming-or-such the content of each file. I believe this is wrong, because that would miss the information that this is actually a *symlink*, and would not detect the fact that is is replacec with an actual file (and hence takes more place on the device than is expected).
Yes, doing a checksum on the host and comparing to the installed target is the functionality I am using to ensure a correct install.
And I still believe it is *wrong* to checksum the content of the files pointed to by a symlink, because it that case, you are missing an important information that it *has* to be a symlink (e.g. in case the tarball is extracted on a filesystem that does not understand symlinks.
But Oh, well, that's not my problem! ;-)
Quoted 7 lines
Quoted 4 lines
I would find it much smarter that:
- files get their content checksumed
- symlinks get their target path checksumed, not the content of the target file (or dir). I.e. symlinks should not be dereferenced.I agree this would be a smarter approach, but I have yet to see a simple utility to do this.
cd /path/to/target/
find . -type f -exec sha1sum {} + >/pat/to/file-list.sha1 find . -type l -exec |while read l; do
printf "%s\t%s\n" "${l}" "$(readlink "${l}")";
done >/pat/to/symlink-list.readlink
Quoted 3 lines
Additionally this was not an issue in previous versions of buildroot before
BR2_SYSTEM_BIN_SHwas created in 2014.11. In the previous version the/bin/shsymlink was just busybox.
I still fail to see that as a problem. ;-) However, that is a change in behaviour, so OK.
Quoted 4 lines
Quoted 4 lines
Quoted 3 lines
system/Config.in +0
-0default "/bin/bash" if BR2_SYSTEM_BIN_SH_BASH default "/bin/dash" if BR2_SYSTEM_BIN_SH_DASH default "/bin/zsh" if BR2_SYSTEM_BIN_SH_ZSH
Quoted 8 lines
Quoted 3 lines
If you contend that
/bin/shbeing an absolute symlink is an issue, then surely the other shells should be treated the same, i.e. they should be madde relative symlinks.I have looked at several different Linux distributions and they all seem to use relative paths for the
/bin/shsymlink. Based on this then the/bin/shsymlink to bash, dash, and zsh should also be updated to be relative.
Well, relative or absolute really does not matter. But for consiistency, we must do the same for all shells. (IMHO)
Quoted 3 lines
Quoted 3 lines
All that matters in the end is that the symlink is correct *on the target". I'm not sure this change is interesting without a good reason; and I don't think you 10.192.168.1gave a good-enough reason; saying "the symlink is different
He! Did I paste an IP adress in there? ;-)
Quoted 6 lines
Quoted 1 line
than what busybox installs" is not a valid reason IMHO.
Dealing with symlinks when you are not on the installed system or in a chroot environment is made more difficult by the use of absolute symlinks. If managing symlinks on the host is required, then just having it correct on the target is not enough.
Again, I fail to see that as a problem. If your tooling is deffective in that it does not understand what a relative symlink is, fix your tooling.
But OK, if you respin with all shells switched to using realtive symlink, and keep the if-clause aligned, I'll ack the patch.
Regards,
Yann E. MORIN.
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------'