[yocto] Removing busybox

Randy MacLeod randy.macleod at windriver.com
Sat Mar 2 10:38:31 PST 2019

On 2/27/19 9:19 PM, Adrian Bunk wrote:
> On Wed, Feb 27, 2019 at 11:59:42PM +0000, Burton, Ross wrote:
>> On Wed, 27 Feb 2019 at 23:55, Tom Rini <trini at konsulko.com> wrote:
>>> My current incomplete list is:
>>>      bind-utils \
>>>      bridge-utils \
>>>      coreutils \
>>>      dnsmasq \
>>>      e2fsprogs \
>>>      e2fsprogs-resize2fs \
>>>      e2fsprogs-tune2fs \
>>>      findutils \
>>>      gawk \
>>>      grep \
>>>      inetutils-ping \
>>>      inetutils-ping6 \
>>>      inetutils-traceroute \
>>>      iproute2 \
>>>      less \
>>>      net-tools \
>>>      parted \
>>>      pciutils \
>>>      procps \
>>>      sed \
>>>      util-linux \
>>>      vim \
>>>      which \
>>> And it's also incomplete as there's more stuff under inetutils I don't
>>> need (but others may), and I set aside patch/diff/ed and some other
>>> stuff I don't need.  And since some of that stuff comes from
>>> meta-openembedded, it's indeed really not clear how/where a packagegroup
>>> would reside as we need things out of meta-networking.
>> That's a good start.  For a oe-core packagegroup

Rather than just a single list per layer, we could do
something similar to:


where we defined an image called 'glibc-core' that tries to be a
close to a minimal set of discrete apps needed to boot to a
command line. Then we provide 10+ package groups that added a (mostly!)
logical set of packages that provide groups of functionality.
The groups and not perfect of course but the ones that we came up
with 5+ years ago are:

For qemux86-64, our images (years old data) vary from:

Image Name    Size (MB)    Comment
==========    =========    =======
glibc-tiny       6+        Trimmed down glibc/busybox/minimal init
glibc-small     50         A standard busybox with sysvint, rsyslog
glibc-core      65         A minimal non-busybox image with
                            sysvinit, rsyslog
glibc-std      350         A more complete non-busybox image with
                            packages that are present for
                            historical reasons.

We also have a WR specific template scheme that lets users add
blocks of functionality (single or multiple packages, kernel configs)
to the images above. I think MarkH has explained that to people before.

Anyway, I'm certainly not suggesting that Yocto would want to
adopt any of this directly but rather I'm just trying to give
an impression of what we use and find useful when contructing 
non-busybox based images. I could revisit the Wind River image
definitions and see if the lists we came up with years ago
could be tweaked, renamed and added to oe-core and meta-oe
to share this approach with other Yocto developers and users for
the an upcoming release, maybe even for 2.8 if people are interested.

I guess the question is if we want to spend time coming to an agreement 
on, testing and maintain these package groups and if they would
really be useful to users since, historically at least, people
who create images tend to be domain experts who can easily write
their own packagegroup file.


> I do not think a core-only packagegroup makes sense when the goal is to
> completely replace busybox (and not just most apps while keeping a few
> busybox apps installed).
>> I'd suggest dropping
>> dnsmasq bridgeutils bindutils to keep it lean.
> The stated usecases are not "lean" but "replace all busybox commands
> with the full versions".
> For that you need bind-utils (in oe-core) for DNS lookup.
>> ...
>> Also swap vim for something in core obviously.
> It is not obvious how to do that.
> What other vi implementation is in core?
> Is there even any good non-busybox non-GUI editor in core?
> Replacing busybox vi with ed would be a bad fit for the
> stated usecases.
> There has to be some vi implementation installed,
> and the "desktop command" implementation is vim.
>> Ross
> cu
> Adrian

# Randy MacLeod
# Wind River Linux

More information about the yocto mailing list