On Thu, 2007-02-08 at 14:49 -0700, Daniel Robbins wrote:
> On 2/8/07, Ned Ludd <solar@g.o> 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 <solar@g.o>
Gentoo Linux

-- 
gentoo-dev@g.o mailing list