Removing busybox

Removing busybox

[Jean-Christian de Rivaz]

Hi all,

After reading the thread "Removing busybox completely from the generated
image" I tested to reproduce the method but this doesn't work as expected.

git clone git://git.yoctoproject.org/poky -b thud
cd poky
echo 'require conf/distro/poky.conf' > meta-poky/conf/distro/poky-ng.conf
echo 'DISTRO = "poky-ng"' >> meta-poky/conf/distro/poky-ng.conf
echo 'VIRTUAL-RUNTIME_base-utils = ""' >> meta-poky/conf/distro/poky-ng.conf
sed -i 's/^DISTRO.*/DISTRO = "poky-ng"/' conf/local.conf
bitbake core-image-minimal
runqemu core-image-minimal kvm

After login as root there still a lot of links to busybox inside /sbin/
/bin/ /usr/sbin/ and /usr/bin/ .

Can someone provides a working method ?

Best Regards,

Jean-Christian de Rivaz

Re: Removing busybox

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 1649 bytes --]

On Wed, Feb 27, 2019 at 01:16:56PM +0100, Jean-Christian de Rivaz wrote:

> Hi all,
> 
> After reading the thread "Removing busybox completely from the generated
> image" I tested to reproduce the method but this doesn't work as expected.
> 
> git clone git://git.yoctoproject.org/poky -b thud
> cd poky
> echo 'require conf/distro/poky.conf' > meta-poky/conf/distro/poky-ng.conf
> echo 'DISTRO = "poky-ng"' >> meta-poky/conf/distro/poky-ng.conf
> echo 'VIRTUAL-RUNTIME_base-utils = ""' >> meta-poky/conf/distro/poky-ng.conf
> sed -i 's/^DISTRO.*/DISTRO = "poky-ng"/' conf/local.conf
> bitbake core-image-minimal
> runqemu core-image-minimal kvm
> 
> After login as root there still a lot of links to busybox inside /sbin/
> /bin/ /usr/sbin/ and /usr/bin/ .
> 
> Can someone provides a working method ?

You're missing a few more things, yes.  What I have is:
# Switch to systemd
DISTRO_FEATURES += "systemd"
VIRTUAL-RUNTIME_init_manager = "systemd"
VIRTUAL-RUNTIME_initscripts = ""
VIRTUAL-RUNTIME_syslog = ""
VIRTUAL-RUNTIME_login_manager = "shadow-base"
DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit"

# Replace busybox
PREFERRED_PROVIDER_virtual/base-utils = "coreutils"
VIRTUAL-RUNTIME_base-utils = "coreutils"
VIRTUAL-RUNTIME_base-utils-hwclock = "util-linux-hwclock"
VIRTUAL-RUNTIME_base-utils-syslog = ""

If you aren't using systemd you'll need to move the login_manager
example over as well, otherwise busybox gets pulled for that.

I'm using the above on thud, today.  And that's not a 1:1 replacement as
my image pulls in a number of other packages for various things I
want/need.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Removing busybox

[Mark Hatle]

[-- Attachment #1.1: Type: text/plain, Size: 1906 bytes --]

On 2/27/19 11:06 AM, Tom Rini wrote:
> On Wed, Feb 27, 2019 at 01:16:56PM +0100, Jean-Christian de Rivaz wrote:
> 
>> Hi all,
>>
>> After reading the thread "Removing busybox completely from the generated
>> image" I tested to reproduce the method but this doesn't work as expected.
>>
>> git clone git://git.yoctoproject.org/poky -b thud
>> cd poky
>> echo 'require conf/distro/poky.conf' > meta-poky/conf/distro/poky-ng.conf
>> echo 'DISTRO = "poky-ng"' >> meta-poky/conf/distro/poky-ng.conf
>> echo 'VIRTUAL-RUNTIME_base-utils = ""' >> meta-poky/conf/distro/poky-ng.conf
>> sed -i 's/^DISTRO.*/DISTRO = "poky-ng"/' conf/local.conf
>> bitbake core-image-minimal
>> runqemu core-image-minimal kvm
>>
>> After login as root there still a lot of links to busybox inside /sbin/
>> /bin/ /usr/sbin/ and /usr/bin/ .
>>
>> Can someone provides a working method ?
> 
> You're missing a few more things, yes.  What I have is:
> # Switch to systemd
> DISTRO_FEATURES += "systemd"
> VIRTUAL-RUNTIME_init_manager = "systemd"
> VIRTUAL-RUNTIME_initscripts = ""
> VIRTUAL-RUNTIME_syslog = ""
> VIRTUAL-RUNTIME_login_manager = "shadow-base"
> DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit"
> 
> # Replace busybox
> PREFERRED_PROVIDER_virtual/base-utils = "coreutils"
> VIRTUAL-RUNTIME_base-utils = "coreutils"
> VIRTUAL-RUNTIME_base-utils-hwclock = "util-linux-hwclock"
> VIRTUAL-RUNTIME_base-utils-syslog = ""
> 
> If you aren't using systemd you'll need to move the login_manager
> example over as well, otherwise busybox gets pulled for that.
> 
> I'm using the above on thud, today.  And that's not a 1:1 replacement as
> my image pulls in a number of other packages for various things I
> want/need.
> 
> 

You can also blacklist busybox to ensure that it never builds, and thus can't
show up in your target image.

PNBLACKLIST[busybox] = "Don't build this"



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 541 bytes --]

Re: Removing busybox

[Burton, Ross]

On Wed, 27 Feb 2019 at 17:27, Mark Hatle <mark.hatle@windriver.com> wrote:
> You can also blacklist busybox to ensure that it never builds, and thus can't
> show up in your target image.
>
> PNBLACKLIST[busybox] = "Don't build this"

Sounds like someone should write a new selftest that does the required
configuration changes as per Tom's mail, blacklists busybox, and then
tries a core-image-sato build.  This would double as a check that we
don't break it in the future, and a documented example of how to do it

Ross

Re: Removing busybox

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 817 bytes --]

On Wed, Feb 27, 2019 at 05:42:03PM +0000, Burton, Ross wrote:
> On Wed, 27 Feb 2019 at 17:27, Mark Hatle <mark.hatle@windriver.com> wrote:
> > You can also blacklist busybox to ensure that it never builds, and thus can't
> > show up in your target image.
> >
> > PNBLACKLIST[busybox] = "Don't build this"
> 
> Sounds like someone should write a new selftest that does the required
> configuration changes as per Tom's mail, blacklists busybox, and then
> tries a core-image-sato build.  This would double as a check that we
> don't break it in the future, and a documented example of how to do it

I'm not sure we can blacklist busybox from the build at this time
(hddimg requires initramfs that requires busybox) but instead only force
remove it from the image and ensure it still builds.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Removing busybox

[Burton, Ross]

On Wed, 27 Feb 2019 at 17:58, Tom Rini <trini@konsulko.com> wrote:
> I'm not sure we can blacklist busybox from the build at this time
> (hddimg requires initramfs that requires busybox) but instead only force
> remove it from the image and ensure it still builds.

Don't build an image with a initramfs?

Re: Removing busybox

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 1181 bytes --]

On Wed, Feb 27, 2019 at 06:35:10PM +0000, Burton, Ross wrote:
> On Wed, 27 Feb 2019 at 17:58, Tom Rini <trini@konsulko.com> wrote:
> > I'm not sure we can blacklist busybox from the build at this time
> > (hddimg requires initramfs that requires busybox) but instead only force
> > remove it from the image and ensure it still builds.
> 
> Don't build an image with a initramfs?

OK, so I've kicked things a bit harder again, and here's what I see as
the (small) rub.
$ git grep hddimg meta/conf/
meta/conf/machine/include/x86-base.inc:IMAGE_FSTYPES ?= "hddimg"

So yes, we can do a test with qemux86/qemux86-64 and documenting this in
local.conf.sample is good (and a packagegroup that gives more 1:1
functionality is on my TODO list somewhere).  But it's also true that
we'll get people with "I can't remove busybox and I tried what it says"
posts since blindly pulling in hddimg gives at least:
ERROR: Nothing RPROVIDES 'busybox-mdev' (but
/home/trini/work/OE/oe-core/meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb
RDEPENDS on or otherwise requires it)

That's the point I want to make, after throwing out a quick test build
dir.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Removing busybox

[Burton, Ross]

On Wed, 27 Feb 2019 at 18:45, Tom Rini <trini@konsulko.com> wrote:
> OK, so I've kicked things a bit harder again, and here's what I see as
> the (small) rub.
> $ git grep hddimg meta/conf/
> meta/conf/machine/include/x86-base.inc:IMAGE_FSTYPES ?= "hddimg"
>
> So yes, we can do a test with qemux86/qemux86-64 and documenting this in
> local.conf.sample is good (and a packagegroup that gives more 1:1
> functionality is on my TODO list somewhere).  But it's also true that
> we'll get people with "I can't remove busybox and I tried what it says"
> posts since blindly pulling in hddimg gives at least:
> ERROR: Nothing RPROVIDES 'busybox-mdev' (but
> /home/trini/work/OE/oe-core/meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb
> RDEPENDS on or otherwise requires it)
>
> That's the point I want to make, after throwing out a quick test build
> dir.

Sure, so the instructions include "don't use hddimg" until we've a way
of not using busybox in the initramfs.

Ross

Re: Removing busybox

[Scott Rifenbark]

[-- Attachment #1: Type: text/plain, Size: 1568 bytes --]

Hi,

Sounds like this issue might have some documentation ripples when it
settles out.

Scott

On Wed, Feb 27, 2019 at 10:46 AM Tom Rini <trini@konsulko.com> wrote:

> On Wed, Feb 27, 2019 at 06:35:10PM +0000, Burton, Ross wrote:
> > On Wed, 27 Feb 2019 at 17:58, Tom Rini <trini@konsulko.com> wrote:
> > > I'm not sure we can blacklist busybox from the build at this time
> > > (hddimg requires initramfs that requires busybox) but instead only
> force
> > > remove it from the image and ensure it still builds.
> >
> > Don't build an image with a initramfs?
>
> OK, so I've kicked things a bit harder again, and here's what I see as
> the (small) rub.
> $ git grep hddimg meta/conf/
> meta/conf/machine/include/x86-base.inc:IMAGE_FSTYPES ?= "hddimg"
>
> So yes, we can do a test with qemux86/qemux86-64 and documenting this in
> local.conf.sample is good (and a packagegroup that gives more 1:1
> functionality is on my TODO list somewhere).  But it's also true that
> we'll get people with "I can't remove busybox and I tried what it says"
> posts since blindly pulling in hddimg gives at least:
> ERROR: Nothing RPROVIDES 'busybox-mdev' (but
> /home/trini/work/OE/oe-core/meta/recipes-core/initrdscripts/
> initramfs-framework_1.0.bb
> RDEPENDS on or otherwise requires it)
>
> That's the point I want to make, after throwing out a quick test build
> dir.
>
> --
> Tom
> --
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>

[-- Attachment #2: Type: text/html, Size: 2357 bytes --]

Re: Removing busybox

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 1374 bytes --]

On Wed, Feb 27, 2019 at 06:47:52PM +0000, Burton, Ross wrote:
> On Wed, 27 Feb 2019 at 18:45, Tom Rini <trini@konsulko.com> wrote:
> > OK, so I've kicked things a bit harder again, and here's what I see as
> > the (small) rub.
> > $ git grep hddimg meta/conf/
> > meta/conf/machine/include/x86-base.inc:IMAGE_FSTYPES ?= "hddimg"
> >
> > So yes, we can do a test with qemux86/qemux86-64 and documenting this in
> > local.conf.sample is good (and a packagegroup that gives more 1:1
> > functionality is on my TODO list somewhere).  But it's also true that
> > we'll get people with "I can't remove busybox and I tried what it says"
> > posts since blindly pulling in hddimg gives at least:
> > ERROR: Nothing RPROVIDES 'busybox-mdev' (but
> > /home/trini/work/OE/oe-core/meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb
> > RDEPENDS on or otherwise requires it)
> >
> > That's the point I want to make, after throwing out a quick test build
> > dir.
> 
> Sure, so the instructions include "don't use hddimg" until we've a way
> of not using busybox in the initramfs.

Yes, I think including a comment about making it clear initramfs' still
need busybox should be enough of a crumb to help users out.  As a
separate thread maybe we should talk about dumping initramfs' from the
default x86 inc file, but that is indeed separate.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Removing busybox

[Jean-Christian de Rivaz]

Thank you very much Tom for help. Here is my complete method:

git clone git://git.yoctoproject.org/poky -b thud
cd poky
cat << EOF > meta-poky/conf/distro/poky-ng.conf
require conf/distro/poky.conf
DISTRO = "poky-ng"

# Switch to systemd
DISTRO_FEATURES += "systemd"
VIRTUAL-RUNTIME_init_manager = "systemd"
VIRTUAL-RUNTIME_initscripts = ""
VIRTUAL-RUNTIME_syslog = ""
VIRTUAL-RUNTIME_login_manager = "shadow-base"
DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit"

# Replace busybox
PREFERRED_PROVIDER_virtual/base-utils = "coreutils"
VIRTUAL-RUNTIME_base-utils = "coreutils"
VIRTUAL-RUNTIME_base-utils-hwclock = "util-linux-hwclock"
VIRTUAL-RUNTIME_base-utils-syslog = ""
EOF
source oe-init-build-env
sed -i 's/^DISTRO.*/DISTRO = "poky-ng"/' conf/local.conf
bitbake core-image-minimal
runqemu core-image-minimal kvm

So as expected systemd is there and busybox is not. But there is a lot of
useful commands missing on the resulting QEMU image:

root@qemux86:~# ps
~sh: ps: command not found
root@qemux86:~# w
~sh: w: command not found
root@qemux86:~# find
~sh: find: command not found
root@qemux86:~# grep
~sh: grep: command not found
root@qemux86:~# ip addr
~sh: ip: command not found

I expected that all the limited busybox commands would be replaced by
the full
featured commands. How to fix that ?

Best Regards.
Jean-Christian de Rivaz

Le 27.02.19 à 18:06, Tom Rini a écrit :
> On Wed, Feb 27, 2019 at 01:16:56PM +0100, Jean-Christian de Rivaz wrote:
>
>> Hi all,
>>
>> After reading the thread "Removing busybox completely from the generated
>> image" I tested to reproduce the method but this doesn't work as expected.
>>
>> git clone git://git.yoctoproject.org/poky -b thud
>> cd poky
>> echo 'require conf/distro/poky.conf' > meta-poky/conf/distro/poky-ng.conf
>> echo 'DISTRO = "poky-ng"' >> meta-poky/conf/distro/poky-ng.conf
>> echo 'VIRTUAL-RUNTIME_base-utils = ""' >> meta-poky/conf/distro/poky-ng.conf
>> sed -i 's/^DISTRO.*/DISTRO = "poky-ng"/' conf/local.conf
>> bitbake core-image-minimal
>> runqemu core-image-minimal kvm
>>
>> After login as root there still a lot of links to busybox inside /sbin/
>> /bin/ /usr/sbin/ and /usr/bin/ .
>>
>> Can someone provides a working method ?
> You're missing a few more things, yes.  What I have is:
> # Switch to systemd
> DISTRO_FEATURES += "systemd"
> VIRTUAL-RUNTIME_init_manager = "systemd"
> VIRTUAL-RUNTIME_initscripts = ""
> VIRTUAL-RUNTIME_syslog = ""
> VIRTUAL-RUNTIME_login_manager = "shadow-base"
> DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit"
>
> # Replace busybox
> PREFERRED_PROVIDER_virtual/base-utils = "coreutils"
> VIRTUAL-RUNTIME_base-utils = "coreutils"
> VIRTUAL-RUNTIME_base-utils-hwclock = "util-linux-hwclock"
> VIRTUAL-RUNTIME_base-utils-syslog = ""
>
> If you aren't using systemd you'll need to move the login_manager
> example over as well, otherwise busybox gets pulled for that.
>
> I'm using the above on thud, today.  And that's not a 1:1 replacement as
> my image pulls in a number of other packages for various things I
> want/need.
>

Re: Removing busybox

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 1738 bytes --]

On Wed, Feb 27, 2019 at 09:06:38PM +0100, Jean-Christian de Rivaz wrote:
> Thank you very much Tom for help. Here is my complete method:
> 
> git clone git://git.yoctoproject.org/poky -b thud
> cd poky
> cat << EOF > meta-poky/conf/distro/poky-ng.conf
> require conf/distro/poky.conf
> DISTRO = "poky-ng"
> 
> # Switch to systemd
> DISTRO_FEATURES += "systemd"
> VIRTUAL-RUNTIME_init_manager = "systemd"
> VIRTUAL-RUNTIME_initscripts = ""
> VIRTUAL-RUNTIME_syslog = ""
> VIRTUAL-RUNTIME_login_manager = "shadow-base"
> DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit"
> 
> # Replace busybox
> PREFERRED_PROVIDER_virtual/base-utils = "coreutils"
> VIRTUAL-RUNTIME_base-utils = "coreutils"
> VIRTUAL-RUNTIME_base-utils-hwclock = "util-linux-hwclock"
> VIRTUAL-RUNTIME_base-utils-syslog = ""
> EOF
> source oe-init-build-env
> sed -i 's/^DISTRO.*/DISTRO = "poky-ng"/' conf/local.conf
> bitbake core-image-minimal
> runqemu core-image-minimal kvm
> 
> So as expected systemd is there and busybox is not. But there is a lot of
> useful commands missing on the resulting QEMU image:
> 
> root@qemux86:~# ps
> ~sh: ps: command not found
> root@qemux86:~# w
> ~sh: w: command not found
> root@qemux86:~# find
> ~sh: find: command not found
> root@qemux86:~# grep
> ~sh: grep: command not found
> root@qemux86:~# ip addr
> ~sh: ip: command not found
> 
> I expected that all the limited busybox commands would be replaced by
> the full
> featured commands. How to fix that ?

Correct, you're missing a lot of stuff.  Somewhere on my (and other
folks too) TODO list is a packagegroup that includes procps and psmisc
and grep and tar and various network packages and less and more and...

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Removing busybox

[Paul Eggleton]

On Thursday, 28 February 2019 9:09:02 AM NZDT Tom Rini wrote:
> Somewhere on my (and other
> folks too) TODO list is a packagegroup that includes procps and psmisc
> and grep and tar and various network packages and less and more and...

That is what packagegroup-core-full-cmdline (well, the packagegroup packages 
that it produces) was intended to be, although I guess there might be some 
argument about what should and should not be in there.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: Removing busybox

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 1042 bytes --]

On Thu, Feb 28, 2019 at 10:31:15AM +1300, Paul Eggleton wrote:
> On Thursday, 28 February 2019 9:09:02 AM NZDT Tom Rini wrote:
> > Somewhere on my (and other
> > folks too) TODO list is a packagegroup that includes procps and psmisc
> > and grep and tar and various network packages and less and more and...
> 
> That is what packagegroup-core-full-cmdline (well, the packagegroup packages 
> that it produces) was intended to be, although I guess there might be some 
> argument about what should and should not be in there.

I'll keep that in mind perhaps if/when I cycle over back over to this.
A packagegroup that says to use busybox isn't what comes to mind when I
want to not have busybox on my image, and so failed out in some of my
earlier local iterations on this when I did a hard blacklist on busybox
and then went off to fixup the fall-out.

I'd also argue that packagegroup both includes "extra" stuff (mc) and
misses other stuff (less).  And I know patches are welcome, so it's on
my TODO list :)

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Removing busybox

[Adrian Bunk]

On Wed, Feb 27, 2019 at 03:09:02PM -0500, Tom Rini wrote:
> On Wed, Feb 27, 2019 at 09:06:38PM +0100, Jean-Christian de Rivaz wrote:
>...
> > So as expected systemd is there and busybox is not. But there is a lot of
> > useful commands missing on the resulting QEMU image:
> > 
> > root@qemux86:~# ps
> > ~sh: ps: command not found
> > root@qemux86:~# w
> > ~sh: w: command not found
> > root@qemux86:~# find
> > ~sh: find: command not found
> > root@qemux86:~# grep
> > ~sh: grep: command not found
> > root@qemux86:~# ip addr
> > ~sh: ip: command not found
> > 
> > I expected that all the limited busybox commands would be replaced by
> > the full
> > featured commands. How to fix that ?
> 
> Correct, you're missing a lot of stuff.  Somewhere on my (and other
> folks too) TODO list is a packagegroup that includes procps and psmisc
> and grep and tar and various network packages and less and more and...

"all the limited busybox commands would be replaced" would be a huge 
list from dc through gawk, minicom and wget to vim.

And would vim-tiny qualify as "the full featured command" of busybox vi,
or should this include vim with full features?

The nice thing about busybox is that it is so small,
in many cases one full featured command alone
is bigger than busybox.

It is not obvious to me what usecases people have in mind for
getting rid of busybox, and whether everyone is aware that
something like "all busybox commands replaced" is *very*
expensive regarding filesystem size.

> Tom

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: Removing busybox

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 2589 bytes --]

On Wed, Feb 27, 2019 at 11:40:37PM +0200, Adrian Bunk wrote:
> On Wed, Feb 27, 2019 at 03:09:02PM -0500, Tom Rini wrote:
> > On Wed, Feb 27, 2019 at 09:06:38PM +0100, Jean-Christian de Rivaz wrote:
> >...
> > > So as expected systemd is there and busybox is not. But there is a lot of
> > > useful commands missing on the resulting QEMU image:
> > > 
> > > root@qemux86:~# ps
> > > ~sh: ps: command not found
> > > root@qemux86:~# w
> > > ~sh: w: command not found
> > > root@qemux86:~# find
> > > ~sh: find: command not found
> > > root@qemux86:~# grep
> > > ~sh: grep: command not found
> > > root@qemux86:~# ip addr
> > > ~sh: ip: command not found
> > > 
> > > I expected that all the limited busybox commands would be replaced by
> > > the full
> > > featured commands. How to fix that ?
> > 
> > Correct, you're missing a lot of stuff.  Somewhere on my (and other
> > folks too) TODO list is a packagegroup that includes procps and psmisc
> > and grep and tar and various network packages and less and more and...
> 
> "all the limited busybox commands would be replaced" would be a huge 
> list from dc through gawk, minicom and wget to vim.
> 
> And would vim-tiny qualify as "the full featured command" of busybox vi,
> or should this include vim with full features?

What to suggest in the busybox-replacement group is a bit of a challenge
as to how far you want to really push things, yes.

> The nice thing about busybox is that it is so small,
> in many cases one full featured command alone
> is bigger than busybox.
> 
> It is not obvious to me what usecases people have in mind for
> getting rid of busybox, and whether everyone is aware that
> something like "all busybox commands replaced" is *very*
> expensive regarding filesystem size.

The use case for not having busybox installed is something like the
project I'm doing where I have 4G of disk space to dedicate to "give me
something like a standard Linux environment".  Since I need to replace
less (doesn't work with systemd PAGER), and I want my usual arguments to
'ps' to work, and then a handful of other things, I want the full
regular versions of utils, and at that point, I want "command not found"
as a reminder to grab what I really want not busybox doing it for me.

All that said, I am a huge fan of busybox when I need to save space.  I
have and continue to push back when customers ask about dropping busybox
for non-technical grounds.  It's also just true that not every case of
an OE use is somewhere that busybox is the best fit.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Removing busybox

[Burton, Ross]

On Wed, 27 Feb 2019 at 21:41, Adrian Bunk <bunk@stusta.de> wrote:
> It is not obvious to me what usecases people have in mind for
> getting rid of busybox, and whether everyone is aware that
> something like "all busybox commands replaced" is *very*
> expensive regarding filesystem size.

Considering many of the people who are trying to not install a single
byte of busybox are also installing toybox, the GPL is often the
reason.  Not sure how to square that with also using Linux though...

Ross

Re: Removing busybox

[Jean-Christian de Rivaz]

Le 27.02.19 à 22:40, Adrian Bunk a écrit :
> On Wed, Feb 27, 2019 at 03:09:02PM -0500, Tom Rini wrote:
>> On Wed, Feb 27, 2019 at 09:06:38PM +0100, Jean-Christian de Rivaz wrote:
>> ...
>>> So as expected systemd is there and busybox is not. But there is a lot of
>>> useful commands missing on the resulting QEMU image:
>>>
>>> root@qemux86:~# ps
>>> ~sh: ps: command not found
>>> root@qemux86:~# w
>>> ~sh: w: command not found
>>> root@qemux86:~# find
>>> ~sh: find: command not found
>>> root@qemux86:~# grep
>>> ~sh: grep: command not found
>>> root@qemux86:~# ip addr
>>> ~sh: ip: command not found
>>>
>>> I expected that all the limited busybox commands would be replaced by
>>> the full
>>> featured commands. How to fix that ?
>> Correct, you're missing a lot of stuff.  Somewhere on my (and other
>> folks too) TODO list is a packagegroup that includes procps and psmisc
>> and grep and tar and various network packages and less and more and...
> "all the limited busybox commands would be replaced" would be a huge 
> list from dc through gawk, minicom and wget to vim.
>
> And would vim-tiny qualify as "the full featured command" of busybox vi,
> or should this include vim with full features?
>
> The nice thing about busybox is that it is so small,
> in many cases one full featured command alone
> is bigger than busybox.
>
> It is not obvious to me what usecases people have in mind for
> getting rid of busybox, and whether everyone is aware that
> something like "all busybox commands replaced" is *very*
> expensive regarding filesystem size.

The project I work for need nodejs and chromium (and a >100MB database
on some nodes), so space is not an issue. I need to deliver an useful
distribution with usual commands, tools and a working console + keyboard
for my locale. If  Poky is only maintained to be tested with sysvinit +
busybox and US locale, then I wonder if it's the appropriate choice for
that project. There nothing wrong in providing a sysvinit + busybox
based small distribution, this is simply not the best fit for that project.

Jean-Christian

>
>> Tom
> cu
> Adrian
>

Re: Removing busybox

[Philip Balister]

On 02/27/2019 05:24 PM, Jean-Christian de Rivaz wrote:
> Le 27.02.19 à 22:40, Adrian Bunk a écrit :
>> On Wed, Feb 27, 2019 at 03:09:02PM -0500, Tom Rini wrote:
>>> On Wed, Feb 27, 2019 at 09:06:38PM +0100, Jean-Christian de Rivaz wrote:
>>> ...
>>>> So as expected systemd is there and busybox is not. But there is a lot of
>>>> useful commands missing on the resulting QEMU image:
>>>>
>>>> root@qemux86:~# ps
>>>> ~sh: ps: command not found
>>>> root@qemux86:~# w
>>>> ~sh: w: command not found
>>>> root@qemux86:~# find
>>>> ~sh: find: command not found
>>>> root@qemux86:~# grep
>>>> ~sh: grep: command not found
>>>> root@qemux86:~# ip addr
>>>> ~sh: ip: command not found
>>>>
>>>> I expected that all the limited busybox commands would be replaced by
>>>> the full
>>>> featured commands. How to fix that ?
>>> Correct, you're missing a lot of stuff.  Somewhere on my (and other
>>> folks too) TODO list is a packagegroup that includes procps and psmisc
>>> and grep and tar and various network packages and less and more and...
>> "all the limited busybox commands would be replaced" would be a huge 
>> list from dc through gawk, minicom and wget to vim.
>>
>> And would vim-tiny qualify as "the full featured command" of busybox vi,
>> or should this include vim with full features?
>>
>> The nice thing about busybox is that it is so small,
>> in many cases one full featured command alone
>> is bigger than busybox.
>>
>> It is not obvious to me what usecases people have in mind for
>> getting rid of busybox, and whether everyone is aware that
>> something like "all busybox commands replaced" is *very*
>> expensive regarding filesystem size.
> 
> The project I work for need nodejs and chromium (and a >100MB database
> on some nodes), so space is not an issue. I need to deliver an useful
> distribution with usual commands, tools and a working console + keyboard
> for my locale. If  Poky is only maintained to be tested with sysvinit +
> busybox and US locale, then I wonder if it's the appropriate choice for
> that project. There nothing wrong in providing a sysvinit + busybox
> based small distribution, this is simply not the best fit for that project.

I have exactly the same needs. Customers with large sd card root for
filesystems want to see desktop commands, not the simpler busybox
commands. We should support both systems.

Philip

> 
> Jean-Christian
> 
>>
>>> Tom
>> cu
>> Adrian
>>
> 

Re: Removing busybox

[Burton, Ross]

On Wed, 27 Feb 2019 at 22:25, Jean-Christian de Rivaz
<jean-christian.derivaz@innodelec.ch> wrote:
> The project I work for need nodejs and chromium (and a >100MB database
> on some nodes), so space is not an issue. I need to deliver an useful
> distribution with usual commands, tools and a working console + keyboard
> for my locale. If  Poky is only maintained to be tested with sysvinit +
> busybox and US locale, then I wonder if it's the appropriate choice for
> that project. There nothing wrong in providing a sysvinit + busybox
> based small distribution, this is simply not the best fit for that project.

Installing the commands is pretty simple: be sure to install all of
util-linux core-utils psutils etc.  Yes, this should be a packagegroup
to make it trivial, but this is practically a few minutes work.

Ross

Re: Removing busybox

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 1698 bytes --]

On Wed, Feb 27, 2019 at 11:02:06PM +0000, Burton, Ross wrote:
> On Wed, 27 Feb 2019 at 22:25, Jean-Christian de Rivaz
> <jean-christian.derivaz@innodelec.ch> wrote:
> > The project I work for need nodejs and chromium (and a >100MB database
> > on some nodes), so space is not an issue. I need to deliver an useful
> > distribution with usual commands, tools and a working console + keyboard
> > for my locale. If  Poky is only maintained to be tested with sysvinit +
> > busybox and US locale, then I wonder if it's the appropriate choice for
> > that project. There nothing wrong in providing a sysvinit + busybox
> > based small distribution, this is simply not the best fit for that project.
> 
> Installing the commands is pretty simple: be sure to install all of
> util-linux core-utils psutils etc.  Yes, this should be a packagegroup
> to make it trivial, but this is practically a few minutes work.

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.
 
-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Removing busybox

[Burton, Ross]

On Wed, 27 Feb 2019 at 23:55, Tom Rini <trini@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 I'd suggest dropping
dnsmasq bridgeutils bindutils to keep it lean. Does that remove
everything from meta-networking?  Also swap vim for something in core
obviously.

Ross

Ross

Re: Removing busybox

[Jean-Christian de Rivaz]

Le 28.02.19 à 00:59, Burton, Ross a écrit :
> On Wed, 27 Feb 2019 at 23:55, Tom Rini <trini@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 I'd suggest dropping
> dnsmasq bridgeutils bindutils to keep it lean. Does that remove
> everything from meta-networking?  Also swap vim for something in core
> obviously.
>
> Ross
>
> Ross

My image recipe look actually like below and require several
meta-openembedded/meta-*. This is not a clean example. The 
packagegroup-core-full-cmdline already provides a chunk of commands but
more are required to look like a modern distribution.

LICENSE = "MIT"

inherit core-image distro_features_check

MACHINE_FEATURES += "acpi"
MACHINE_FEATURES += "apm"
MACHINE_FEATURES += "keyboard"
MACHINE_FEATURES += "pcbios"
MACHINE_FEATURES += "pci"
MACHINE_FEATURES += "rtc"
MACHINE_FEATURES += "screen"
MACHINE_FEATURES += "serial"
MACHINE_FEATURES += "wifi"

REQUIRED_DISTRO_FEATURES = "x11"
DISTRO_FEATURES += "keyboard"
DISTRO_FEATURES += "ldconfig"

IMAGE_FEATURES += "splash"
IMAGE_FEATURES += "x11-base"
IMAGE_FEATURES += "package-management"
IMAGE_FEATURES += "ssh-server-openssh"
IMAGE_FEATURES += "tools-debug"

IMAGE_INSTALL += "python-modules python-misc"
IMAGE_INSTALL += "packagegroup-core-full-cmdline"
IMAGE_INSTALL += "e2fsprogs-mke2fs"
IMAGE_INSTALL += "parted"
IMAGE_INSTALL += "iproute2-ss"
IMAGE_INSTALL += "iproute2-tc"
IMAGE_INSTALL += "iproute2-lnstat"
IMAGE_INSTALL += "iproute2-ifstat"
IMAGE_INSTALL += "iproute2-genl"
IMAGE_INSTALL += "iproute2-rtacct"
IMAGE_INSTALL += "iproute2-nstat"
IMAGE_INSTALL += "iproute2-ss"
IMAGE_INSTALL += "iproute2-tipc"
IMAGE_INSTALL += "kmod"
IMAGE_INSTALL += "wget"
IMAGE_INSTALL += "iputils-ping"
IMAGE_INSTALL += "less"
IMAGE_INSTALL += "vim"
IMAGE_INSTALL += "nano"

IMAGE_INSTALL += "glibc-utils"
IMAGE_INSTALL += "glibc-gconv-cp1252"
IMAGE_INSTALL += "glibc-charmap-cp1252"
IMAGE_INSTALL += "ldd"
IMAGE_INSTALL += "sysstat"
IMAGE_INSTALL += "gettext"
IMAGE_INSTALL += "curl"
IMAGE_INSTALL += "socat"
IMAGE_INSTALL += "htop"
IMAGE_INSTALL += "autossh"

IMAGE_INSTALL += "cronie"
IMAGE_INSTALL += "networkmanager"
IMAGE_INSTALL += "ethtool"
IMAGE_INSTALL += "ntp"
IMAGE_INSTALL += "openssh-sshd"
IMAGE_INSTALL += "rsync"
IMAGE_INSTALL += "git"

Re: Removing busybox

[Burton, Ross]

On Thu, 28 Feb 2019 at 00:10, Jean-Christian de Rivaz
<jean-christian.derivaz@innodelec.ch> wrote:
> My image recipe look actually like below and require several
> meta-openembedded/meta-*. This is not a clean example. The
> packagegroup-core-full-cmdline already provides a chunk of commands but
> more are required to look like a modern distribution.
>
> LICENSE = "MIT"
>
> inherit core-image distro_features_check
>
> MACHINE_FEATURES += "acpi"
> MACHINE_FEATURES += "apm"
> MACHINE_FEATURES += "keyboard"
> MACHINE_FEATURES += "pcbios"
> MACHINE_FEATURES += "pci"
> MACHINE_FEATURES += "rtc"
> MACHINE_FEATURES += "screen"
> MACHINE_FEATURES += "serial"
> MACHINE_FEATURES += "wifi"

None of those will have an impact.

> REQUIRED_DISTRO_FEATURES = "x11"
> DISTRO_FEATURES += "keyboard"
> DISTRO_FEATURES += "ldconfig"

Neither will those.

Ross

Re: Removing busybox

[Adrian Bunk]

On Wed, Feb 27, 2019 at 11:59:42PM +0000, Burton, Ross wrote:
> On Wed, 27 Feb 2019 at 23:55, Tom Rini <trini@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

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

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: Removing busybox

[Burton, Ross]

On Thu, 28 Feb 2019 at 05:20, Adrian Bunk <bunk@stusta.de> wrote:
> > That's a good start.  For a oe-core packagegroup
>
> 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).

But a "close enough" packagegroup in core would be a good starting point.

> > 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.

Good point well made.
> > 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.

I thought we had some other editor in core, but can't see one.  Worse
case we still use busybox for its vi... :)

Ross

Re: Removing busybox

[Richard Purdie]

On Thu, 2019-02-28 at 12:05 +0000, Burton, Ross wrote:
> On Thu, 28 Feb 2019 at 05:20, Adrian Bunk <bunk@stusta.de> wrote:
> > > That's a good start.  For a oe-core packagegroup
> > 
> > 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).
> 
> But a "close enough" packagegroup in core would be a good starting
> point.
> 
> > > 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.
> 
> Good point well made.
> > > 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.
> 
> I thought we had some other editor in core, but can't see one.  Worse
> case we still use busybox for its vi... :)

This could be an argument for pulling a small number of things into OE-
Core too...

Cheers,

Richard

Re: Removing busybox

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 1721 bytes --]

On Thu, Feb 28, 2019 at 02:27:37PM +0000, Richard Purdie wrote:
> On Thu, 2019-02-28 at 12:05 +0000, Burton, Ross wrote:
> > On Thu, 28 Feb 2019 at 05:20, Adrian Bunk <bunk@stusta.de> wrote:
> > > > That's a good start.  For a oe-core packagegroup
> > > 
> > > 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).
> > 
> > But a "close enough" packagegroup in core would be a good starting
> > point.
> > 
> > > > 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.
> > 
> > Good point well made.
> > > > 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.
> > 
> > I thought we had some other editor in core, but can't see one.  Worse
> > case we still use busybox for its vi... :)
> 
> This could be an argument for pulling a small number of things into OE-
> Core too...

Moving the vim recipe (which doesn't have further depends) over and then
putting VIRTUAL-RUNTIME_vim and ?= "vim-tiny" in this packagegroup
should be flexible enough, yes?

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Removing busybox

[Richard Purdie]

On Thu, 2019-02-28 at 09:37 -0500, Tom Rini wrote:
> On Thu, Feb 28, 2019 at 02:27:37PM +0000, Richard Purdie wrote:
> > On Thu, 2019-02-28 at 12:05 +0000, Burton, Ross wrote:
> > > I thought we had some other editor in core, but can't see
> > > one.  Worse
> > > case we still use busybox for its vi... :)
> > 
> > This could be an argument for pulling a small number of things into
> > OE-
> > Core too...
> 
> Moving the vim recipe (which doesn't have further depends) over and
> then
> putting VIRTUAL-RUNTIME_vim and ?= "vim-tiny" in this packagegroup
> should be flexible enough, yes?

Yes.

Cheers,

Richard

Re: Removing busybox

[Jean-Christian de Rivaz]

Le 28.02.19 à 06:19, Adrian Bunk a écrit :
> On Wed, Feb 27, 2019 at 11:59:42PM +0000, Burton, Ross wrote:
>> ...
>> 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.

I have see numbers of users trying nano before falling back to vim or
vi. The nano editor is standard on Debian and Ubuntu making a lot of
users expecting it more intuitive interface.

Jean-Christian

Re: Removing busybox

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 812 bytes --]

On Wed, Feb 27, 2019 at 05:42:03PM +0000, Burton, Ross wrote:
> On Wed, 27 Feb 2019 at 17:27, Mark Hatle <mark.hatle@windriver.com> wrote:
> > You can also blacklist busybox to ensure that it never builds, and thus can't
> > show up in your target image.
> >
> > PNBLACKLIST[busybox] = "Don't build this"
> 
> Sounds like someone should write a new selftest that does the required
> configuration changes as per Tom's mail, blacklists busybox, and then
> tries a core-image-sato build.  This would double as a check that we
> don't break it in the future, and a documented example of how to do it

Can you point me at a test that just does a 'bitbake -g' or similar
check-don't-build type test and I'll go off and add this to my series
that adds packagegroup-core-base-utils?  Thanks!

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Removing busybox

[Randy MacLeod]

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@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:

https://github.com/WindRiver-Labs/wrlinux/blob/WRLINUX_10_17_BASE/wrlinux-distro/recipes-base/images/wrlinux-image-glibc-core.bb

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:
 
https://github.com/WindRiver-Labs/wrlinux/tree/WRLINUX_10_18_BASE/wrlinux-distro/recipes-base/packagegroups


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.

../Randy

> 
> 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