Erik Andersen <[EMAIL PROTECTED]> writes: > The current busybox.deb needs a little work (about 1 hour) before it > will be ready to replace the one in boot-floppies. Mostly, I need > to go through and turn off everything that isn't enabled in the > boot-floppies CVS. Also, some of the choices re what to enable or > disable in busybox (such as sed) should be re-considered. For > example, busybox sed has been rewritten (again) and may well do the > job now.
Yes, you should just go ahead and enable whatever you think should be enabled. So long as you mark that in the changelog I can make the necessary changes for woody boot-floppies. > The next thing that needs to be done is deciding on the method by > which busybox gets its applet links installed. Busybox now supports > a runtime '/bin/busybox --install [-s]' command to install hard (or > soft) links for each and every busybox applet. Using this method, > the only thing that actually needs to be installed is /bin/busybox > (or /sbin/init or wherever you put it). I recommend we use this > method to install all the needed links at runtime. This will ensure > that the set of links we install is _always_ in sync with the > binary. On the downside, there is a chance that you might get an > EEXIST error (it will not overwrite existing binaries with links) > when it tries to install something that already exists on the > boot-floppies filesystem, but at least that make things easy to > debug... > I would be happy to integrate this support into boot-floppies (just > adds a couple of lines into /etc/rc.d/rcS). Ok -- lets wait until I branch for woody. I wanna get 2.2.21 out. > I can probably get at least the initial part of this work done this weekend. > > > - dealing with new kernel (what is the proposed kernel for woody, > > anyhow?) > Well, the updated busybox (unlike the version in the boot-floppies > CVS), copes gracefully with 2.4 kernels so that, at least, isn't > going to be a problem anymore... Beyond that (where busybox wouldn't > boot on 2.4.x kernels) the only real issue I can think of is how we > handle all the new kernel modules... Yes -- that's a modconf issue, isn't it? -- .....Adam Di [EMAIL PROTECTED]<URL:http://www.onShore.com/>
