On Thu, 2007-02-08 at 14:49 -0700, Daniel Robbins wrote: > On 2/8/07, Ned Ludd <[EMAIL PROTECTED]> wrote: > > As somebody that's had to hand write many of those kinds of scripts. A > > single rcS is not very ideal. Our init scripts are in fact mostly usable > > by busybox. Granted there are a few special special cases, but then Roy > > is offering to update those for free. One of the larger problems really > > boils down to many packages provide default init.d scripts and these > > expect the existing baselayout only. That will be a bigger feat to deal > > with later on down the road. > > Developers will then need to test their init.d scripts to ensure that > they are compatible with busybox. This is asking a lot of work of > people just so you can use Gentoo's initscripts for something they are > not really ideal for.
I don't think anybody can/would expect that. They don't test for hardened or uClibc now before stabilizing a pkg. What would be nice to see is if a maintainer is offered a posix compliant init.d script that they merge it or allow those to be merged for a pkg they maintain as long as it does not degrade functionality. > Any time a script is updated a new rev of a > package is required, and this does impact users and will cause > packages to be rebuilt when a user does "emerge -u". So I think this > should be weighed against the potential benefits of baselayout + > busybox. busybox is not Roys underlying goal as far as I understand. I think he simply mentioned it as an example of another group who wishes to unify efforts and have an interest in getting away from arrays where feasible. > If you are targetting something smaller than 32MB, then maybe busybox > is appropriate. But you are trying to go really small, then you > probably don't want all the extra junk in our initscripts. And if you > are _not_ trying to go really small, then put bash in your filesystem, > not busybox, and the initscripts will work. If bash isn't fast enough > from a boot time perspective, then the gentoo initscripts certainly > aren't going to be fast enough either. > > In other words: > > busybox + single rcS file = fastest and simplest, smallest, best for > very small filesystems, not as flexible > > bash + gentoo baselayout = most flexible, biggest, slower, best for > feature-rich systems > > busybox + gentoo baselayout = ? It's been done in the past by end users. Before there were only about 4 changes needed to make it work. That all changed when bash arrays were introduced. > I think that in 99 out of 100 cases, if you have room for baselayout, > then you probably have room for bash too. And in 99 out of 100 cases, > if you can deal with the load time of baselayout, then you can deal > with the overhead that might be incurred from having bash. > > I'm just pointing out that it's not an obviously good combination. In > the grand scheme of things, maybe it's not a great use of developer > resources. Or, maybe I'm wrong and it is a great idea. His time and resources. His "itch" > Personally I think that "baselayout + busybox" may be cool, but adding > an aftermarket sunroof to your car can be cool too. But that doesn't > mean it's worth the effort :) I don't think those who are not interested in this will be burden by any extra effort. Worst case is maybe getting a bug assigned to you which offers a posix replacement/update for the default init.d a pkg you maintain might provide. > Really, it's hard for me to imagine many scenarios where you really > need the flexibility of baselayout but can't squeeze in bash. And I > have a pretty good imagination. baselayout is only about a half of a meg these days and probably getting smaller/faster with the addition of the multicall rc/runscript work he has been doing. Adding bash also requires ncurses which in turn mostly requires having a c++ aware compiler or using the nocxx,minimal flags. Even with those flags enabled I'm seeing 3M going to ncurses+bash. So I can for sure see the benefits. Also for a moment lets stop and think. Some XYZ update breaks ncurses/bash. Supporting this gives us a nice alternative way to still boot our boxes for rescue using ash or another shell which might not have such big deps. -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
