* Re: Removing busybox
2019-02-27 21:40 ` Adrian Bunk
@ 2019-02-27 21:46 ` Tom Rini
2019-02-27 21:49 ` Burton, Ross
2019-02-27 22:24 ` Jean-Christian de Rivaz
2 siblings, 0 replies; 32+ messages in thread
From: Tom Rini @ 2019-02-27 21:46 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Yocto discussion list
[-- 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 --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Removing busybox
2019-02-27 21:40 ` Adrian Bunk
2019-02-27 21:46 ` Tom Rini
@ 2019-02-27 21:49 ` Burton, Ross
2019-02-27 22:24 ` Jean-Christian de Rivaz
2 siblings, 0 replies; 32+ messages in thread
From: Burton, Ross @ 2019-02-27 21:49 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Tom Rini, Yocto discussion list
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
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Removing busybox
2019-02-27 21:40 ` Adrian Bunk
2019-02-27 21:46 ` Tom Rini
2019-02-27 21:49 ` Burton, Ross
@ 2019-02-27 22:24 ` Jean-Christian de Rivaz
2019-02-27 22:58 ` Philip Balister
2019-02-27 23:02 ` Burton, Ross
2 siblings, 2 replies; 32+ messages in thread
From: Jean-Christian de Rivaz @ 2019-02-27 22:24 UTC (permalink / raw)
To: Adrian Bunk, Tom Rini; +Cc: Yocto discussion list
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
>
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Removing busybox
2019-02-27 22:24 ` Jean-Christian de Rivaz
@ 2019-02-27 22:58 ` Philip Balister
2019-02-27 23:02 ` Burton, Ross
1 sibling, 0 replies; 32+ messages in thread
From: Philip Balister @ 2019-02-27 22:58 UTC (permalink / raw)
To: Jean-Christian de Rivaz, Adrian Bunk, Tom Rini; +Cc: Yocto discussion list
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
>>
>
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Removing busybox
2019-02-27 22:24 ` Jean-Christian de Rivaz
2019-02-27 22:58 ` Philip Balister
@ 2019-02-27 23:02 ` Burton, Ross
2019-02-27 23:54 ` Tom Rini
1 sibling, 1 reply; 32+ messages in thread
From: Burton, Ross @ 2019-02-27 23:02 UTC (permalink / raw)
To: Jean-Christian de Rivaz; +Cc: Tom Rini, Yocto discussion list
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
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Removing busybox
2019-02-27 23:02 ` Burton, Ross
@ 2019-02-27 23:54 ` Tom Rini
2019-02-27 23:59 ` Burton, Ross
0 siblings, 1 reply; 32+ messages in thread
From: Tom Rini @ 2019-02-27 23:54 UTC (permalink / raw)
To: Burton, Ross; +Cc: Yocto discussion list
[-- 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 --]
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: Removing busybox
2019-02-27 23:54 ` Tom Rini
@ 2019-02-27 23:59 ` Burton, Ross
2019-02-28 0:10 ` Jean-Christian de Rivaz
2019-02-28 5:19 ` Adrian Bunk
0 siblings, 2 replies; 32+ messages in thread
From: Burton, Ross @ 2019-02-27 23:59 UTC (permalink / raw)
To: Tom Rini; +Cc: Yocto discussion list
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
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Removing busybox
2019-02-27 23:59 ` Burton, Ross
@ 2019-02-28 0:10 ` Jean-Christian de Rivaz
2019-02-28 0:11 ` Burton, Ross
2019-02-28 5:19 ` Adrian Bunk
1 sibling, 1 reply; 32+ messages in thread
From: Jean-Christian de Rivaz @ 2019-02-28 0:10 UTC (permalink / raw)
To: Burton, Ross, Tom Rini; +Cc: Yocto discussion list
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"
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Removing busybox
2019-02-28 0:10 ` Jean-Christian de Rivaz
@ 2019-02-28 0:11 ` Burton, Ross
0 siblings, 0 replies; 32+ messages in thread
From: Burton, Ross @ 2019-02-28 0:11 UTC (permalink / raw)
To: Jean-Christian de Rivaz; +Cc: Tom Rini, Yocto discussion list
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
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Removing busybox
2019-02-27 23:59 ` Burton, Ross
2019-02-28 0:10 ` Jean-Christian de Rivaz
@ 2019-02-28 5:19 ` Adrian Bunk
2019-02-28 12:05 ` Burton, Ross
` (2 more replies)
1 sibling, 3 replies; 32+ messages in thread
From: Adrian Bunk @ 2019-02-28 5:19 UTC (permalink / raw)
To: Burton, Ross; +Cc: Tom Rini, Yocto discussion list
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
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: Removing busybox
2019-02-28 5:19 ` Adrian Bunk
@ 2019-02-28 12:05 ` Burton, Ross
2019-02-28 14:27 ` Richard Purdie
2019-02-28 15:30 ` Jean-Christian de Rivaz
2019-03-02 18:38 ` Randy MacLeod
2 siblings, 1 reply; 32+ messages in thread
From: Burton, Ross @ 2019-02-28 12:05 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Tom Rini, Yocto discussion list
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
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Removing busybox
2019-02-28 12:05 ` Burton, Ross
@ 2019-02-28 14:27 ` Richard Purdie
2019-02-28 14:37 ` Tom Rini
0 siblings, 1 reply; 32+ messages in thread
From: Richard Purdie @ 2019-02-28 14:27 UTC (permalink / raw)
To: Burton, Ross, Adrian Bunk; +Cc: Tom Rini, Yocto discussion list
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
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Removing busybox
2019-02-28 14:27 ` Richard Purdie
@ 2019-02-28 14:37 ` Tom Rini
2019-02-28 14:55 ` Richard Purdie
0 siblings, 1 reply; 32+ messages in thread
From: Tom Rini @ 2019-02-28 14:37 UTC (permalink / raw)
To: Richard Purdie; +Cc: Yocto discussion list, Adrian Bunk
[-- 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 --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Removing busybox
2019-02-28 14:37 ` Tom Rini
@ 2019-02-28 14:55 ` Richard Purdie
0 siblings, 0 replies; 32+ messages in thread
From: Richard Purdie @ 2019-02-28 14:55 UTC (permalink / raw)
To: Tom Rini; +Cc: Yocto discussion list, Adrian Bunk
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
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Removing busybox
2019-02-28 5:19 ` Adrian Bunk
2019-02-28 12:05 ` Burton, Ross
@ 2019-02-28 15:30 ` Jean-Christian de Rivaz
2019-03-02 18:38 ` Randy MacLeod
2 siblings, 0 replies; 32+ messages in thread
From: Jean-Christian de Rivaz @ 2019-02-28 15:30 UTC (permalink / raw)
To: Adrian Bunk, Burton, Ross; +Cc: Tom Rini, Yocto discussion list
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
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Removing busybox
2019-02-28 5:19 ` Adrian Bunk
2019-02-28 12:05 ` Burton, Ross
2019-02-28 15:30 ` Jean-Christian de Rivaz
@ 2019-03-02 18:38 ` Randy MacLeod
2 siblings, 0 replies; 32+ messages in thread
From: Randy MacLeod @ 2019-03-02 18:38 UTC (permalink / raw)
To: Adrian Bunk, Burton, Ross; +Cc: Tom Rini, Yocto discussion list
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
^ permalink raw reply [flat|nested] 32+ messages in thread