More busybox replacements (dCore 5.0rc3)

[cpoakes]

@Jason - A quick survey of my /bin, /usr/bin, /sbin, and /usr/sbin shows the following are still linked to busybox when the normal package is installed.

Package adduser (replacements are actually in /usr/bin):
/bin/addgroup
/bin/adduser
/bin/delgroup
/bin/deluser

Package coreutils:
/bin/nice
/usr/bin/readlink

Package debianutils:
/usr/bin/which

Package login:
/bin/login
/bin/su

Package mount:
/bin/mount
/sbin/swapon
/sbin/swapoff

Package passwd:
/usr/bin/passwd
/usr/sbin/chpasswd

Package procps:
/usr/bin/free
/usr/bin/pkill
/usr/bin/pgrep
/usr/bin/uptime

Package util-linux:
/bin/more
/usr/bin/getopt
/sbin/fdisk
/sbin/fsck
/sbin/getty
/sbin/hwclock
/sbin/mkswap

The general assumption is the packaged versions are equivalent and more complete.  While I believe this true for this list, the mount command is an exception.  The busybox version of mount contains builtin support for NFS and NTFS; "regular" debian mount requires packages nfs-common and ntfs-3g to do the same but is not dependent on them.  Supplanting busybox mount will break the current functionality.  Preserving busybox mount may preclude the complete feature set for NFS and NTFS.  Perhaps this requires a more complex "rule" - the busybox link is only replaced when packages mount AND nfs-common or ntfs-3g are installed.

Thx

Updated with:

Package sysvinit-utils:
/bin/pidof
/usr/bin/mesg
/usr/bin/last
/sbin/sulogin

[Rich]

Hi cpoakes
Don't those packages have their programs in  /usr/local/sbin  and  /usr/local/bin? If they do, they should override the
busybox commands since they show up first in the PATH environmental variable.

[Jason W]

cpoakes - thank you for the list, I will try to knock it out today as I have a rare day off from work.  I will ponder the mount issue and hopefully a good plan can be found.

Rich - Debian doesn't place files in /usr/local, they are all in the traditional /usr, /usr/bin, /bin, /sbin, /usr/sbin paths.  Though some things in Debian install into /usr/bin where our busybox has it's file in /bin, and in that case the busybox one would be overridded in $PATH.

[Jason W]

I have replaced the busybox files mentioned here with ones from the packages using the startup scripts.  With the exception of mount, which I will deal with later.

[cpoakes]

@Jason - Thanks.  Will stay tuned to see how mount is resolved.

@RIch - Hi.  Yes, I had noticed the PATH override.  Two issues...  First, only common usage prioritizes /usr/bin over /bin in PATH; it is not a requirement.  The user shouldn't need a specific PATH order to ensure they use an installed command.  Second, I would argue dCore should track Debian as close as possible to prevent inadvertent breakage.  The redundant /bin versions should be removed, however unlikely they are to cause a problem.

[tinypoodle]

First, only common usage prioritizes /usr/bin over /bin in PATH; it is not a requirement.

If prioritizing of PATH is disregarded as requirement, then in consequence only the usage of full path can ensure invoking a specific version of an executable.

Second, I would argue dCore should track Debian as close as possible to prevent inadvertent breakage.  The redundant /bin versions should be removed, however unlikely they are to cause a problem.

Removing essential commands from base could potentially result in system malfunction.

[cpoakes]

Hi TP,
You misunderstand.  I am not saying the order in the path is irrelevant.  I am saying my path can quite legitimately be PATH=/bin:/usr/bin.  And even though common usage generally reverses that order to prioritize /usr/bin over /bin, that common usage is not required.

Nothing us being removed; it is being replaced and in a different location.  SysAdmins have decades of experience dealing with standard Unix commands found in differing locations (the /bin, /usr/bin, /usr/local/bin crapshoot).  A script with a command hardwired to a specific directory, like /bin/adduser, is not portable and at risk for breakage; I consider it an error.