Re: disposition of boot-floppies in woody
Erik Andersen <andersen@codepoet.org> 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 Carlo....adam@onShore.com.....<URL:http://www.onShore.com/>
Reply to: