When thinking about modularization, I realized that how to deal with busybox takes some special care. For instance, if all the symlinks were listed in a busybox.files or busybox.list or whatever a specific package manager uses, then the package manager would have to take special care when dealing with busybox because if one chose to uninstall or upgrade busybox via the package manager then removing what once was a symlink could actually result in removing a full utility that was installed after busybox. Apt/dpkg actually complains and refuses to install if you try to install a package which has a file in common with an existing package. In this case the solution is to delete the file from the metadata (i.e. filelist) of the previously installed package prior to installing the new package via apt/dpkg.
So the solution for apt/dpkg is not to include any of these symlinks in the metadta if they conflict with another package in the repo. This means that when one removes a package one could be left with broken symlinks unless there was a suitable uninstall script to clean up these symlinks. And in the case of debian there likely is such an uninstall script.
In the case of puppy, rather then having specific package manager data about busybox there is a file called /bin/busybox.lst. One might wonder if this list differs at all from the command, "busybox --list-full". It might be the case for instance that items that would overwrite a puppy specific script such as df or mount are excluded (I'll verify this). In the case of fossapup this doesn't apear to be the case. /bin/mount is listed in this list but this conflicts with the puppy specific mount script.
As a side note, @wiak suggests that putting busybox sylinks is a non-standard location may cause issues (see post). However, I notice a script in my version of fatdog64, which I think is the official called bb-symlinks.sh
Code: Select all
#!/bin/sh
DISABLE_USR="s@^usr/@@"
BB=busybox
! [ -e bin/busybox ] && echo Run from chroot directory && exit
case $1 in
install)
$QEMU_ARM bin/busybox --list-full | $BB sed "$DISABLE_USR" | while read -r p; do
if ! [ -e $p ]; then
ln -s ../bin/busybox $p
fi
done
;;
remove)
find . -type l | while read -r p; do
if $BB readlink $p | $BB grep -q busybox; then
rm $p
fi
done
;;
"") echo install or remove.
;;
esac
Of interest in this script is that it has the option "DISABLE_USR="s@^usr/@@"", which essentially strips the "usr" part from the path of where the symlink is intalled. On Fatdog64 this makes since because I believe that the /bin directory lies near the end of the "$PATH" string and as of consequence has the lowest priority. I think in puppy the opposite is the case and this is likely so that puppy specific scripts such as "mount" and "df" take precedence. Also perhaps puppy tries to minimize the full utility dependecies and so having some full utilities executed by default might help towards this aim.
That said, there are certain full utilities that I would like to take precidence such as realpath and tar. If in most cases one wanted busybox utilities to take precedence then they could have a specific directory that links to the specific full utilities that they want to take precedence and then this directory for overwriding busybox could be put at the front of the "$PATH" string.
Similarly, if puppy specific scripts should take precedence there there could be a specific directory for the puppy specific scripts (see post) and (github issue), that should take precedence. Furthermore, if there was such a directory for puppy specific scripts then it would be possible to place the "/bin" directory near the end of the "$PATH" string as seems to be the case for fatdog64.
Related discussion:
- Isolated puppy scripts #2086
- rc.sysinit: Added isolated folder #2091
- Create README.TXT #2092
- My post regarding how a n isolation folder might help facilitate modularization
But the essence is the same.