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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org