Puppy Linux Discussion Forum

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

#!/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

Yes precedence is an issue that needs considered.

Related is what I did in my original January release of WDLGO_UbuntuFocal64

viewtopic.php?p=15540#p15540

For that one, I created a folder /usr/local/firstrib/bin and put busybox and all symlinks to it in there and put that directory at the end of the PATH, and hence of lowest exec priority.

Reason being that apt/dpkg wouldn't grumble and any full version of utility would end up with higher precedence (though like I mentioned somewhere in tests in something I was doing, maybe not with that, I had an issue with certain busybox applets if they weren't in the location structure given by busybox --list-full).

Reading that github issue you posted link to, where rizalmart recently suggested the exact opposite to what I did (since I wanted upstream-provided applets to get precedence rather than local busybox), it seems most woof-CE developers don't see any issue with files preference for Puppy itself. I wouldn't know, but I wouldn't be surprised if there is...

I may say, because I now think the safest option for busybox symlinks is indeed to use the paths given by busybox --list-full, I decided not to use /usr/local/firstrib/bin structure in later releases. Also, I somehow don't like having to make a local bin directory in that way that involves modifying PATH in that fashion (despite that it works). It is one case where I certainly wouldn't like the /usr/local/.../bin to take precedence over /usr/bin and so on (though local normally would be expected take precedence) since it somewhat interferes with upstream repo install expectations, which could at times break things if what is in local/.../bin isn't compatible enough.

Indeed I have already changed that strategy in main WDL builds - now I prefer to only use busybox static to get things working, but once package manager becomes available I replace that static busybox with upstream busybox via the package manager (assuming I still want busybox on final system, which I normally do). I generally scrub the original busybox symlinks prior to doing that.

I may say, the busybox issue, as described above, is easy to deal with for both upstream Void Linux and Arch Linux case since /bin, /sbin, are simply symlinks to /usr/bin anyway. Indeed, from doing a recent Ubuntu debootstrap creation it seems that Debian has also moved away from using separate /bin, /sbin, /usr/bin and so on... I'd have to double-check that, but it seems to be the case now. Reason the list-full issue/need becomes easier is that everything then ends up in /usr/bin anyway...

wiak wrote: Sun Mar 21, 2021 11:35 pm

now I prefer to only use busybox static to get things working

Exactly the same conclusion was reached by the developers of one of the main branches of russian version of Puppy. True, they argue and swear all the time But the essence is the same.

Grey wrote: Mon Mar 22, 2021 2:57 am

wiak wrote: Sun Mar 21, 2021 11:35 pm

now I prefer to only use busybox static to get things working

Exactly the same conclusion was reached by the developers of one of the main branches of russian version of Puppy. True, they argue and swear all the time But the essence is the same.

I prefer static busybox even though a dynamically linked busybox has a smaller relative footprint. I like the busybox in tinycore because it is separated into two files, which are those that require su and those that don't. Unfortunately, tinycore doesn't use a static busybox. I wonder if I could edit the ELF file for the tinycore busybox to use relative linking to the tinycore glibc.

I run into this problem a lot trying to do some essentially arcane projects. The BB versions of standard utils are missing many of the switches and features of the full, 'official' versions. My solution is to manually compile and install the mainstream versions I need in the same directory (/bin) and add an underscore after the binary name (i.e.: 'mount_', or 'ping_' ), then make the symlink point to the underscored version. The full version will sit right next to the symlink in the file manager. Then the only maintenance that is needed is maintaining the symlinks to do what suits my system.