On Mon, Feb 14, 2011 at 11:37, Michael Tokarev <[email protected]> wrote: > [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!]
Debian Installer Team. Obviously there're people that usually care about the package and thus are the 'maintainers' on team. Currently those are Colin, Bastian and I. > 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. Surely there's many wrong assumptions on the config handling but at same time we weren't much focused on non-d-i usage. More bellow. > 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. Indeed. Please enable it for them all. > 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? Enable it. > 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? I agree and it would be good to 'use it' on d-i but this needs more testing and integration (probably) then just enabling it. We could leave it for a second moment after we get busybox in a better shape and you guys get used to d-i. > 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? For regular and static I'd say we could provide as most as possible but udeb is the opposite. > 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? busybox is a core of d-i and provides all the "coreutils" used on d-i as a whole. We try to keep d-i as small as possible and that is important since we boost the installation requirements due changes on d-i. So we try to have it as small as possible. > How the static flavour is used? Is it supposed to > contain everything that regular deb contains? If > not, why? as regular deb. > 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? Not sure. Maks, do you know if initramfs-tools depends on those? > 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). Agreed. > I'd like to bring this functionality and flexibility > to Debian. Sure. So let's work torvalds this direction. IMO the best way of starting is you proposing a branch with the thing you'd like to change for merging and we review it together. Cheers, -- Otavio Salvador O.S. Systems E-mail: [email protected] http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/AANLkTi=+RmiaAx_=_vQOZ9T=gtufyr<[email protected]
