[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

[2nd try] busybox: config options and purpose of subpackages



[Resending my email from Dec-2010.  What I'd want to get
 is some unification and review of config options enabled,
 but the main question actually is: who maintains busybox
 nowadays?  Thanks!]

Hello.

I wonder who/how decides to enable/disable various config
options in the 3 different flavours of busybox packages.
There are a lot of differences between the configs which -
in my opinion - should not be there.

For example: md5sum -c (check) is enabled for udeb flavour,
but not for regular deb or static flavour.  Udeb is supposed
to be smaller, yet it contains extra feature like this, and
there's no reason this particular feature should not be
enabled in 2 regular flavours.

Another example, -m option for tar (FEATURE_TAR_NOPRESERVE_TIME)
is enabled for deb and udeb flavours but is not enabled for
static flavour.  Why?

Long time ago modutils implementation were disabled in
busybox, mostly due to their brokeness.  People hoped
that for etch or lenny it will come back, but it was
quite some years ago.  Nowadays, busybox module support
is mature enough to go on-par with module-init-tools,
but the applets are still disabled.  Is there any
particular reason for this?

Debian BTS has lots of wishlist items about enabling various
features, especially for the udeb flavour.

And now I come to my second question: what's the
purpose of busybox and 3 different flavours of the
package?  Should it enable all features as is done
for most other packages, or just a few selected
(by whom? for what?) applets/features?

How the udeb is used?  Is it supposed to contain some
rescue tools so that one can boot from an installer
CD (or even from a netboot image) and the included
busybox is useful for some system maintenance?
How really small it should be nowadays, when even
the kernel does not fit in a floppy anymore - is there
a reason to try hard to keep it small?

How the static flavour is used?  Is it supposed to
contain everything that regular deb contains?  If
not, why?

Regular deb and static flavours are linked against
libm - for two applets, awk and dc (FEATURE_AWK_LIBM
and FEATURE_DC_LIBM).  Is this really necessary for
something?  Where dc and awk are used _and_ math
support is required?

I'd like to make the set of enabled features/options
to be more or less the same, at least between the
two regular debs (since udeb is really special as
it's used by d-i only), and enable some more applets.

Nowadays, busybox is almost enough to act as a complete
rescue system in initramfs - everything from module
loading to mounting the root filesystem is implemented
and works, including nfs root, live CD and other fun
stuff.  Some subsystems need their own tools, for
example mdadm and lvm, iscsi and similar.

I even used busybox-only initramfs to fix/rescue boot
problems on remote machines - boot into initramfs, bring
up the network (not normally done), run nc -l -e sh
and connect to this port from remote machine to perform
diagnostics and to fix boot issues.  All this with
a busybox binary which is just a bit larger than the
one currently used in Debian, but without libm (so
the resulting initramfs image is smaller).

I'd like to bring this functionality and flexibility
to Debian.

Thanks!

/mjt


Reply to: