The $Subj basically says it all.
I'm trying to review configuration of different busubox
packages, but I don't really see the intention for some
of them, especially for the -static flavour of it.
As originally created by Erik Andersen back in early
2000s, busybox-static intended to be a rescue/repairment
tool in case you break your system so that regular tools
based on dynamic glibc does not work. But I don't think
it is used for such purposes nowadays by anyone, since it
may be easier to boot some rescue CD or USB image, even
the debian-installer will do for that.
I've been told that static busybox _may_ be used by embedded
systems, or for testing of such systems with qemu which may
have issues loading dynamically-linked executables, but for
these, separate custom config/build is used instead of the
Also, Hector Oron mentioned Crush, and an attempt to use
busybox there instead of regular tools like coreutils,
but this, again, uses its own package named busybox-crush,
and its development has been postproned.
Is busybox-static package actually in use? Do you have
suggestions for its configuration?
A full "allyesconfig" of today busybox is a 13-megabytes
binary (statically linked with glibc), I doubt such a
monster is really needed (and it will grow with more
applets are added to busybox). Obviously some line
has to be drawn somewhere, -- no need to enable just
_everything_. But in order to understand what to
enable, some understanding of intended usage is a
good thing to have, too..
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org