[yocto] busybox->coreutils: How replace single Busybox program with same from coreutils

[Paul Eggleton]

Hi Ulf,

On Saturday, 11 November 2017 7:59:00 PM NZDT Ulf Samuelsson wrote:
> Adding a third party package to the rootfs, and some of their scripts
> will break due to the busybox version of certain applications
> do not support all the switches.
> 
> Rather that rewriting those scripts (forcing me to maintain them)
> I would like to replace the busybox version of selected applications
> with the coreutils version.
> 
> I would like to avoid adding other coreutils applications to the rootfs,
> since their is a requirement for a small rootfs.
> The core functionality is to be in a cramfs, so deleting files 
> postinstall is not working.
> 
> One application is "od" or octal dump.
> 
> My first try was a bbappend with
> ALTERNATIVE_PRIORITY[od]	= "100"
> 
> Since the busybox version has priority "50", the coreutils version 
> should be choosen, but the rootfs still choose the busybox version.
> 
> I then added "coreutils" to my image.
> This, I expected would add all the applications in the coreutils
> package so I set
> 
> ALTERNATIVE_PRIORITY[<app>]	= "5"
> for all applications supported by busybox,
> and
> ALTERNATIVE_PRIORITY[<app>]	= "0"
> for all applications not supported by busybox (and not needed by me)
> in the (vain) hope that this would result in the application not beeing
> included in the rootfs.
> 
> The result was that the rootfs now included the coreutils
> version of the desired application.
> 
> Unfortunately this also resulted in all applications with priority "0"
> being included in the rootfs as well.
> 
> Have not tried with any other value but a quick inspection of the python 
> code led me to believe that there is no value which will make
> 
> ===============================================================
> SUGGESTION:
> I think it would be a good addition to the class, if you could specify a 
> priority which excluded the application from the rootfs.
> "0", "-1" or "No" would be good values
> ===============================================================
> 
> Other alternatives I am thinking of is to add to the 
> coreutils_%.bbappend file.
> 
> FILES_${PN}-<app> = " ${bindir}/<app>"
> or maybe
> FILES_${PN}-<app> = " ${bindir}/<app>.coreutils"
> 
> Have not tested this yet, but this I guess may result in the application
> beeing present in two packages.
> 
> Is the following valid?
> 
> FILES_${PN} = " ${bindir}"
> FILES_${PN}-od = " ${bindir}/od.${BPN}"
> 
> Will it create two packages, each with their own "od", or will
> the second statement override the first so that "od" is only
> present in the coreutils-od package?
> 
> ===============================================================
> I could always create a do_install_append and install the applications
> as something else
> 
> do_install_append () {
> 	install	-m 0755 <x>/od		${D}/usr/local/bin/od
> }
> FILES_${PN}-od = " /usr/local/bin/od"
> ===============================================================
> Fully replacing the do_install is yet another alternative.
> Since the coreutils
> ===============================================================
> Checking the meta/recipes-core/coreutils/coreutils_8.27.bb
> it might be as easy as replacing the bindir_progs variable
> only listing those applications I want.
> 
> bindir_progs = "od install mktemp"
> ALTERNATIVE_${PN} = "od install mktemp"
> ===============================================================
> Any other ideas?
> 
> Is overriding busybox with the "real" application documented somewhere?
> If not, maybe it should be.

coreutils already does override busybox when installed, at least where the 
alternatives definitions are set up. I'm not sure if the definitions are 
complete though.

Surely the answer to your specific problem is to break up coreutils into 
smaller packages for the items you need? We've done that for some of the tools 
already, I'm sure we'd accept further patches, but failing that a bbappend 
will let you do that locally.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre