On Sat Dec 30, 2000 at 01:48:00PM -0500, Adam Di Carlo wrote: > > Anthony Towns claimed on debian-devel that it would take us "a few > months" to prepare boot-floppies for woody. I think it can be done by > Feb. I don't think there many major issues. Here's the one's I know > of: > > - use busybox.deb from woody rather than the local CVS copy
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. 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). 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... -Erik -- Erik B. Andersen email: [EMAIL PROTECTED] --This message was written using 73% post-consumer electrons--
