On Wed, 16 Feb 2011 21:15:57 +0000 Otavio Salvador <ota...@ossystems.com.br> wrote:
> On Wed, Feb 16, 2011 at 21:06, Neil Williams <codeh...@debian.org> > wrote: ... > > I cannot recommend any embedded system should use any version of > > busybox built by Debian for d-i without *also* installing and using > > coreutils, login, passwd, shadow, perl and all the rest. i.e. > > busybox from Debian is only suitable for what Debian normally does > > with busybox > > - which explicitly does *not* include handling passwords, shadow or > > otherwise. > > Please take a look on this thread: > http://lists.debian.org/debian-boot/2011/02/msg00471.html > > Basically we're going to revamp busybox and busybox-static > configuration (d-i one is not going to be changed too much) and then > we wish to try to be more "friendly" to this kind of use-cases. As I'm sure you're aware, busybox is not one package, it's 50 or more - and that's just counting the common variations in source configuration, not counting the variations of C library used. > Doing the proposed changes I guess we fit this gab. Only in the static model, which explains why the binary is so large. Emdebian Crush shipped with a binary of ~700kb but that was a much older version. Embedded users who want a static version are probably going to want a static version linked against uClibc and with no coreutils, login, passwd etc. installed and all symlinks enabled. I don't see how Debian can even test such a configuration, let alone recommend it for widespread usage. I think the best option is for d-i to simply keep up with busybox releases. (Current stable is 1.18.3, Debian has 1.17.1, even with bubulle's update since Squeeze.) That is, itself, a signficant challenge for a busy and overworked team like d-i and has proved to be an unreachable target before - especially once a release process starts up and the rest of d-i needs so much testing. Busybox needs to freeze early, that's entirely understandable. The "standard" build won't be (ever) able to install the symlinks which actually make busybox useful for embedded devices. (It can be hard to run something on device to create the symlinks when the device cannot boot because the symlinks don't exist.) The only real solution would be a fourth build with the symlinks enabled but which conflicts with dpkg, coreutils, login, passwd and numerous other utilities. I tried to make this fourth build available just for a single architecture via cross-building - it is a lot of work. This doesn't even start to handle the more common instance where the device needs a customised busybox configuration in the first place. It's a bigger problem than kernels because users who want busybox want busybox because there isn't room on the system for anything else and every 10kb less in /bin/busybox makes it worth reconfiguring and rebuilding it. Trying to be friendly is a good thing - adding work for the d-i team which still means that busybox needs to be reconfigured and rebuilt for actual embedded devices anyway isn't being friendly - either to the rest of the d-i team or the embedded users. > Most important: what's the usage for the static build? Umm, exactly - not much IMHO. In the opinion of the dpkg maintainers, around the time of the Lenny freeze, a system which replaces coreutils, dpkg and passwd is "not Debian any more". In the opinion of many embedded developers, a system with a full size busybox *and* coreutils, dpkg and the rest is simply wasting precious space. I don't want to be overly negative over this, I'm just trying to ensure that a commendable desire to be friendly does not actually result in wasting time within the d-i team and then turn out to not be useful to embedded users. IMHO, the best thing d-i can do is to ensure that Debian stays as close to the current busybox stable release as possible. Updating to current upstream stable as soon as possible after the release is done and ensuring it is again updated before the next freeze takes hold. That's a minimum of only two updates per release cycle, but updates which go directly to latest upstream stable. It will necessarily slip during all release freezes but that one commitment may well be enough. Rebuilding from a Debian source package with adjusted configuration is a lot more friendly than using wget on busybox.net. Keep the deb and udeb configuration exactly as d-i requires - maybe even drop the static version if d-i doesn't use it. Just keep the package up to date and it will make embedded use a lot simpler than trying to mangle together some incomplete, broken configuration which isn't directly usable. -- Neil Williams ============= http://www.linux.codehelp.co.uk/
pgprrywdQGAKp.pgp
Description: PGP signature
