Bug#375568: busybox-static should include "Provides: busybox"
06.05.2011 18:09, Bastian Blank wrpte:
> On Fri, May 06, 2011 at 05:55:58PM +0400, Michael Tokarev wrote:
>> 15.01.2008 01:03, Jameson Rollins wrote:
>>> Hello. I would like to get an update on the status of this bug.
>>> Right now, busybox-static is basically uninstallable on any system
>>> that needs initramfs-tools, which I imagine is most. The proposed
>>> solution would work, ie. set "Provides: busybox". I would really like
>>> to use this tool but can't at the moment.
>
> initramfs-tools does not depend on busybox.
initramfs-tools does not depend on busybox indeed, but it
recommends busybox|busybox-initramfs. With default apt
settings that basically translates to depends, since
all Recommends are installed too.
>> I'd like to let the two packages co-exist with each other
>> instead of conflicting. I'm not sure for now how to
>> achieve this.
>
> Why?
>
>> Merely "Providing" busybox in busybox-static,
>> while should work, is wrong IMHO, because the two are used
>> for different purposes, and it's not wise to replace bb in
>> initramfs with busybox-static just by installing -static
>> flavour. Also, no one (I think) tested -static build in
>> initramfs, and I'm not sure it will ever work... ;)
>
> They are used for the same purpose, one tool.
No, the purpose is actually different. And for added fun,
I for one do NOT know the purpose of busybox-static, why
people use it for in reality, except of several somewhat
obscure cases.
Regular busybox build is used for initramfs (to "enhance"
it with some rescue abilities if nothing else) and for other
"regular" tasks - like small dhcp client, like one or two
utils which sometimes aren't installed but busybox provides
and the like. There, regular busybox is the way to go
really - with shared regular glibc.
For static busybox, the usage question is more interesting.
Long time ago, especially when there was libc5 => libc6
transition, I wanted to have some tool like busybox,
statically linked to be independent of any current library
mess, so that it's possible to fix a broken system after
some unsuccessful libc6 install/upgrade, -- live, without
rebooting. So at least one potential usage is to have
busybox-static floating around somewhere just in case it
will be needed someday, when everything else fails.
That's completely different scenario.
As of using busybox-static in initramfs instead of regular
busybox - we already have 2 libc in initramfs, it's already
too much, there's no need to have THREE of them in there.
I mean, klibc, regular glibc for stuff like mdadm, cryptoloop
and other things which uses glibc, and also glibc statically
linked into busybox. (There, I'd offer a choice - use
glibc OR klibc, instead of klibc or (klibc+glibc), but that's
different issue entirely).
One possibility is to have busybox-static install into /sbin
instead of /bin. That goes on-par with the usage example I
outlined above, sort of, but is a bit ugly too.
/mjt
Reply to: