Skip to contentSkip to conversation

procps-ng: remove the remaining busybox symlinks

PATCH New Vicente Olivert Riera 4 participants 7 messages Jan 12, 2016 – Jan 13, 2016

lore
Share & tools
lore

Vicente Olivert Riera

author
#0 lore raw

PATCH 1/1 procps-ng: remove the remaining busybox symlinks

procps-ng is installed after busybox to ensure that its tools overwrite the ones installed by busybox. However, some busybox symlinks for tools which are now provided by procps-ng remain in /bin and /sbin pointing to the busybox binary.

This shouldn't be a problem since the /usr/bin directory is listed before /bin in the $PATH variable. However there could be some scripts out there hardcoding the path of those tools calling them by "/bin/ps" for instance.

So in order to avoid potential problems we just remove all busybox symlinks for the tools which are now provided by procps-ng.

Signed-off-by Vicente Olivert Riera <[email protected]>
---
 package/procps-ng/procps-ng.mk | 15 +++++++++++++++
 1 file changed, 15 insertions(+)
package/procps-ng/procps-ng.mk +15 -0
index 07e98b9..784977d 100644
@@ -17,8 +17,23 @@ PROCPS_NG_GETTEXTIZE = YES
 
 # If both procps-ng and busybox are selected, make certain procps-ng
 # wins the fight over who gets to have their utils actually installed.
+# Also remove the remaining busybox symlinks for tools which are now
+# provided by procps-ng.
 ifeq ($(BR2_PACKAGE_BUSYBOX),y)
 PROCPS_NG_DEPENDENCIES += busybox
+
+define PROCPS_NG_REMOVE_BUSYBOX_COUNTERPARTS
+	for i in free kill pgrep pidof pkill pmap ps pwdx slabtop tload top uptime vmstat w watch; do \
+		if [ "$$(readlink $(TARGET_DIR)/bin/$$i)" == "busybox" ]; then \
+			rm $(TARGET_DIR)/bin/$$i; \
+		fi; \
+	done
+
+	if [ "$$(readlink $(TARGET_DIR)/sbin/sysctl)" == "../bin/busybox" ]; then \
+		rm $(TARGET_DIR)/sbin/sysctl; \
+	fi
+endef
+PROCPS_NG_POST_INSTALL_TARGET_HOOKS += PROCPS_NG_REMOVE_BUSYBOX_COUNTERPARTS
 endif
 
 ifeq ($(BR2_NEEDS_GETTEXT_IF_LOCALE),y)
Signature · 1 line
2.4.10
#1 lore raw

PATCH 1/1 procps-ng: remove the remaining busybox symlinks

Vicente,

Quoted 34 lines · Vicente Olivert Riera

procps-ng is installed after busybox to ensure that its tools overwrite the ones installed by busybox. However, some busybox symlinks for tools which are now provided by procps-ng remain in /bin and /sbin pointing to the busybox binary.

This shouldn't be a problem since the /usr/bin directory is listed before /bin in the $PATH variable. However there could be some scripts out there hardcoding the path of those tools calling them by "/bin/ps" for instance.

So in order to avoid potential problems we just remove all busybox symlinks for the tools which are now provided by procps-ng.

Signed-off-by Vicente Olivert Riera <[email protected]>
---
 package/procps-ng/procps-ng.mk | 15 +++++++++++++++
 1 file changed, 15 insertions(+)
package/procps-ng/procps-ng.mk +6 -0
index 07e98b9..784977d 100644
@@ -17,8 +17,23 @@ PROCPS_NG_GETTEXTIZE = YES
 
 # If both procps-ng and busybox are selected, make certain procps-ng
 # wins the fight over who gets to have their utils actually installed.
+# Also remove the remaining busybox symlinks for tools which are now
+# provided by procps-ng.
 ifeq ($(BR2_PACKAGE_BUSYBOX),y)
 PROCPS_NG_DEPENDENCIES += busybox
+
+define PROCPS_NG_REMOVE_BUSYBOX_COUNTERPARTS
+	for i in free kill pgrep pidof pkill pmap ps pwdx slabtop tload top uptime vmstat w watch; do \
+		if [ "$$(readlink $(TARGET_DIR)/bin/$$i)" == "busybox" ]; then \

package/procps-ng/procps-ng.mk PROCPS_NG_GETTEXTIZE = YES · line 37

Quoted 10 lines
package/procps-ng/procps-ng.mk +9 -0
+			rm $(TARGET_DIR)/bin/$$i; \
+		fi; \
+	done
+
+	if [ "$$(readlink $(TARGET_DIR)/sbin/sysctl)" == "../bin/busybox" ]; then \
+		rm $(TARGET_DIR)/sbin/sysctl; \
+	fi
+endef
+PROCPS_NG_POST_INSTALL_TARGET_HOOKS += PROCPS_NG_REMOVE_BUSYBOX_COUNTERPARTS
 endif

I don't think we're doing it this way for any other package. In general, we either:

* Arrange for the package to install its tools at the same location as Busybox installs them.

* Or add a post-install hook to move the binaries installed by the package to where Busybox installs them.

Peter, Yann ?

Thomas

Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
#2 lore raw

PATCH 1/1 procps-ng: remove the remaining busybox symlinks

Thomas, Vicente, All,

On 2016-01-12 21:12 +0100, Thomas Petazzoni spake thusly:

Quoted 11 lines · Vicente Olivert Riera
Quoted 10 lines

procps-ng is installed after busybox to ensure that its tools overwrite the ones installed by busybox. However, some busybox symlinks for tools which are now provided by procps-ng remain in /bin and /sbin pointing to the busybox binary.

This shouldn't be a problem since the /usr/bin directory is listed before /bin in the $PATH variable. However there could be some scripts out there hardcoding the path of those tools calling them by "/bin/ps" for instance.

Quoted 4 lines
Quoted 4 lines

So in order to avoid potential problems we just remove all busybox symlinks for the tools which are now provided by procps-ng.

Signed-off-by Vicente Olivert Riera <[email protected]>

[--SNIP--]

Quoted 10 lines

I don't think we're doing it this way for any other package. In general, we either:

* Arrange for the package to install its tools at the same location as Busybox installs them.

* Or add a post-install hook to move the binaries installed by the package to where Busybox installs them.

Peter, Yann ?

Yes, I agree with Thomas. First solution is preferred if possible, of course, so that we don't have to maintain the list of executables to move in the post-install hook.

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.  |
'------------------------------^-------^------------------^--------------------'
#3 lore raw

PATCH 1/1 procps-ng: remove the remaining busybox symlinks

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

"Yann" == Yann E MORIN <[email protected]> writes:

Hi,

Quoted 6 lines
Quoted 6 lines

I don't think we're doing it this way for any other package. In general, we either:

* Arrange for the package to install its tools at the same location as Busybox installs them.

Quoted 8 lines
Quoted 4 lines

* Or add a post-install hook to move the binaries installed by the package to where Busybox installs them.

Peter, Yann ?

Yes, I agree with Thomas. First solution is preferred if possible, of course, so that we don't have to maintain the list of executables to move in the post-install hook.

Agreed. If you need to go for the second option make sure it is only done if !BR2_ROOTFS_MERGED_USR.

Signature · 2 lines
Venlig hilsen,
Peter Korsgaard
author
#4 lore raw

PATCH 1/1 procps-ng: remove the remaining busybox symlinks

Hello Peter, Thomas, Yann,

Quoted 13 lines · Peter Korsgaard
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

"Yann" == Yann E MORIN <[email protected]> writes:

Hi,

Quoted 9 lines
Quoted 9 lines

I don't think we're doing it this way for any other package. In general, we either:

* Arrange for the package to install its tools at the same location as Busybox installs them.

* Or add a post-install hook to move the binaries installed by the package to where Busybox installs them.

Quoted 9 lines
Quoted 5 lines
Quoted 1 line

Peter, Yann ?

Yes, I agree with Thomas. First solution is preferred if possible, of course, so that we don't have to maintain the list of executables to move in the post-install hook.

Agreed. If you need to go for the second option make sure it is only done if !BR2_ROOTFS_MERGED_USR.

configuring procps-ng for installing its binaries in /bin and /sbin (first option suggested by Thomas) mostly works, except for two tools (pidof and watch) which are installed in /usr/bin and their busybox counterparts still exist in /bin.

configuring procps-ng for installing its binaries in /bin and /sbin doesn't mean that all its binaries will end up in /bin and /sbin. Some of them are still installed in /usr/bin and /usr/sbin.

So, I see three options here:

1 - follow the second suggestion from Thomas (post-install hook to move the ALL binaries installed by the package to where Busybox installs them)

2 - same thing but only move pidof and watch binaries

3 - remove /bin/pidof and /bin/watch symlinks installed by Busybox

I happy with any of them, so, which one do you prefer?

Regards,

Vincent.

#5 lore raw

PATCH 1/1 procps-ng: remove the remaining busybox symlinks

Vicente,

Quoted 10 lines · Vicente Olivert Riera

So, I see three options here:

1 - follow the second suggestion from Thomas (post-install hook to move the ALL binaries installed by the package to where Busybox installs them)

2 - same thing but only move pidof and watch binaries

3 - remove /bin/pidof and /bin/watch symlinks installed by Busybox

I happy with any of them, so, which one do you prefer?

I think my personal preference would be to install as many procps-ng tools as possible in the "right" place, and then only move the few ones for which you can't configure the installation location.

On a side note, it would be interesting to write a tool that looks if there are two binaries in bin/, sbin/, usr/bin/ and usr/sbin/ with the same name, in order to automatically detect at the end of the build if we have two commands (one full implementation and one from Busybox) that are installed in different locations.

Best regards,

Thomas

Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
#6 lore raw

PATCH 1/1 procps-ng: remove the remaining busybox symlinks

Quoted 12 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

"Thomas" == Thomas Petazzoni <[email protected]> writes:

Vicente,

Quoted 7 lines · Vicente Olivert Riera

So, I see three options here:

1 - follow the second suggestion from Thomas (post-install hook to move the ALL binaries installed by the package to where Busybox installs them)

2 - same thing but only move pidof and watch binaries

Quoted 7 lines
Quoted 3 lines

3 - remove /bin/pidof and /bin/watch symlinks installed by Busybox

I happy with any of them, so, which one do you prefer?

I think my personal preference would be to install as many procps-ng tools as possible in the "right" place, and then only move the few ones for which you can't configure the installation location.

Indeed, me too. I don't think we want more than 1 of the "same" binary on a system, and E.G. have scripts behave differently if they call the tools without specifying any path or hardcoding /bin/<tool>.

Quoted 5 lines

On a side note, it would be interesting to write a tool that looks if there are two binaries in bin/, sbin/, usr/bin/ and usr/sbin/ with the same name, in order to automatically detect at the end of the build if we have two commands (one full implementation and one from Busybox) that are installed in different locations.

Yes, that could be a nice check.

Signature · 2 lines
Venlig hilsen,
Peter Korsgaard