On Mon, Feb 14, 2011 at 11:37, Michael Tokarev 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: ota...@ossystems.com.br http://www.ossystems.com.br
Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/AANLkTi=+RmiaA
